Skip to content

Navigation Menu

Sign in
Appearance settings

Search code, repositories, users, issues, pull requests...

Provide feedback

We read every piece of feedback, and take your input very seriously.

Saved searches

Use saved searches to filter your results more quickly

Appearance settings

feat(introduction_screen): Enable override* buttons to receive onPressed callback #234

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Open
wants to merge 1 commit into
base: master
Choose a base branch
Loading
from

Conversation

flowhorn
Copy link

🚀 Summary

This PR enhances the existing override* button APIs (overrideDone, overrideNext, overrideSkip, overrideBack) by passing them an onPressed callback. Consumers can now supply fully custom widgets and wire up the built-in navigation logic, without having to manually hook into IntroductionScreenState.


🧩 Motivation

Currently, overrideDone (and its siblings) accept a Widget?, which makes it impossible to integrate the built-in navigation behavior (e.g. advancing to the next page, skipping). Users who want a custom button must:

  1. Provide their own widget.
  2. Manually call navigation methods on the GlobalKey<IntroductionScreenState>.

This is cumbersome and error-prone. By passing the onPressed handler directly to the override builder, we:

  • Promote DRY: reuse existing navigation callbacks.
  • Simplify usage: consumer only needs to define appearance.
  • Ensure consistent behavior across all buttons.

🛠️ Implementation

  • Signature change

    // Before
    final Widget? overrideDone;
    
    // After
    final Widget Function(BuildContext context, VoidCallback? onPressed)? overrideDone;
  • Apply the same pattern to:

    • overrideNext
    • overrideSkip
    • overrideBack
  • Internally, when rendering an override button:

    if (overrideDone != null) {
      child = overrideDone!(context, _handleDone);
    } else {
      child = done;
    }
  • Where _handleDone is the existing navigation callback that invokes onDone and advances the screen.


🔍 Usage Example

IntroductionScreen(
  pages: pages,
  overrideDone: (context, onPressed) {
    return ElevatedButton.icon(
      icon: const Icon(Icons.check_circle),
      label: const Text("Let’s Go!"),
      style: ElevatedButton.styleFrom(
        primary: Colors.green,
        shape: RoundedRectangleBorder(borderRadius: BorderRadius.circular(12)),
      ),
      onPressed: onPressed, // Automatically calls `onDone`
    );
  },
  onDone: () {
    // Custom completion logic
  },
);

All other override parameters work identically:

overrideNext: (ctx, onPressed) => MyCustomNextButton(onPressed: onPressed),
overrideSkip: (ctx, onPressed) => TextButton(onPressed: onPressed, child: Text("Skip")),
overrideBack: (ctx, onPressed) => IconButton(icon: Icon(Icons.arrow_back), onPressed: onPressed),

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

1 participant
Morty Proxy This is a proxified and sanitized view of the page, visit original site.