Skip to content
This repository has been archived by the owner on Jun 23, 2022. It is now read-only.

Router implementation not behaving as expected #2

Open
dgaedcke opened this issue Nov 21, 2020 · 2 comments
Open

Router implementation not behaving as expected #2

dgaedcke opened this issue Nov 21, 2020 · 2 comments

Comments

@dgaedcke
Copy link

dgaedcke commented Nov 21, 2020

Looking in the design spec here

The delegate itself is a Listenable, which the Router widget is subscribed to. Whenever the delegate wants to change how the Navigator is configured (e.g. change the list of Pages provided to the Navigator), it notifies its listeners, which will cause the Router widget to rebuild. As part of that rebuild the Router asks the routerDelegate for a correctly configured Navigator instance, which the Router will incorporate into the tree.

This implies that "notifyListeners" on the RouterDelegate is SUPPOSED to force a rebuild of the navigator.
See line 44 in your MaterialApp.router implementation

In your example, (and in mine), I can't get the router to request a rebuild from the delegate simply by calling "notifyListeners". My router never even requests the FIRST navigator on app-start. I'm having to do what you've done (line 51) and wrap my navigator in it's own responsive (Consumer) builder.

Are the specs wrong or are you and I missing something in our implementation?

I'll link to this over on the flutter repo for their comments

@orestesgaolin
Copy link
Owner

That sounds strange indeed. When trying for the first time I used Consumer a bit unconsciously just to make sure that the Navigator will get rebuilt on each change. Your point seems to be true, that if I subscribe to ChangeNotifier's notifications in RouterDelegate it should just rebuild the Navigator the same way as I do with Consumer.

Hopefully I'll have some time this week to investigate this a bit and see if there's some error on my side.

@dgaedcke
Copy link
Author

I don't know what you discovered, but in my case it was user error ... you can close this unless removing that consumer breaks your implementation ... in which case you should post a msg on that linked issue. Otherwise, I've told them they can close it ...

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

No branches or pull requests

2 participants