Skip to content

Flutter Web + Modular navigation: best practice for multi-step flows (pushNamed vs navigate) and resize behavior #1037

@gabser

Description

@gabser

Hi, and thanks for your work on Flutter Modular 👋

I'm using Flutter Modular in a large modular Flutter Web application (Flutter 3.38.2, Dart 3.10.x, Modular 6.4.1).
Here is the architecture context and the question.


Architecture summary

- Top-level CoreModule building a page with a RouterOutlet
- Each feature is a separate Module
- Inside modules, navigation currently uses Modular.to.pushNamed()

Example route structure:

/feature/book   → Book page  
/feature/search → Search page

Both pages share state through singleton Cubits, but are different routes.


Issue observed on Flutter Web

Navigation from Book → Search is done via:

Modular.to.pushNamed('/feature/search');

This keeps the previous route (/feature/book) in the Navigator stack.

When resizing the browser window while on /feature/search:

- Flutter rebuilds ALL routes in the stack (including the offstage Book route)
- Widgets in the hidden route may trigger assertions during rebuild
  (focused TextField, Autocomplete overlay, OverlayEntry, etc.)

This behavior is consistent with Flutter:
multiple active routes → multiple widget trees → all rebuilt on resize.


❓ Main question: best practice for multi-step navigation on Flutter Web

Given a two-step internal flow:

Step 1: /feature/book  
Step 2: /feature/search

where I do not need browser-like push/pop history:

Is it recommended to use Modular.to.navigate() or pushReplacementNamed() instead of pushNamed()?

This would keep only one route alive, avoiding hidden offstage trees.

Is this the recommended Modular pattern for multi-step flows on Web?


Performance considerations

pushNamed → multiple routes alive → multiple trees rebuilt on resize  
navigate/pushReplacement → one active route → fewer rebuilds, more stability

Is this interpretation correct from Modular’s perspective?
Or does Modular internally manage stacked routes differently?


Overlays & route stacking

Are there known limitations when stacking routes with pushNamed, such as:

- Autocomplete popups still mounted
- OverlayEntry not fully disposed
- FocusNode/RenderObject inconsistencies

Should these always be manually cleaned before pushNamed,
or is Modular’s recommended approach on Web to avoid stacking altogether?


Goal

I’m trying to determine the best practice for:

- Multi-step internal flows inside a module
- Preventing offstage widget trees from causing asserts during browser resize
- Ensuring optimal performance by keeping a single active widget tree

I can provide a minimal reproducible example if needed.

Thanks for any clarification or guidance 🙏


Metadata

Metadata

Assignees

No one assigned

    Labels

    newNew issue request attentionquestionQuestions about using some feature or general working of the package

    Type

    No type
    No fields configured for issues without a type.

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions