Hello, thanks for the feedback!

About routing, you really want to keep the logic about where and how you're navigating to in the view model, so you can unit test it as well as have complex routing systems depending on user interactions, like you mentioned, after an API call, for example.

Now, you don't want to access widgets, context, Navigators, etc in the view model, you only want the pure logic in there, such as the routing logic.

If you want a spoiler of the next post showing how I do it, have a look at the part 2 of the series code github.com/CassiusPacheco/flutter_mvvm/commit/fbd…

The post explaining it will be coming up soon. Hope that helps!

Good news Ali, I've just posted the part 2 of the series that explains routing cassiuspacheco.com/flutter-mvvm-and-clean-archite…

Cassius Pacheco

hi cassius, this is great and thank you very much for the quick response. it is funny that right after sending this message I also came up with a similar solution. although in my case I opted in to having each view model to define its own possible routes, so that it doesn’t have the full power of accessing anywhere in the app. so it emits events from the view model (such as emitting second event to the navigationEvents publish subject) which gets observed in the view state and then view state does the navigation.

i liked the fact that you abstracted the observation part and put that to the base class. also liked the AppRouteAction enum you defined to even further abstract the routing.

great job for one of the most complete and clean flutter architecture post.