Questions or comments for the routing packages research report

[InMatrix]

We have finally finished our research on routing packages and made our report available for everyone to download. Please take a look and use this thread to post any questions or comments you might have. We'd love to know in what way the results of this research are useful to you, either as a package author or a Flutter user evaluating routing APIs. Thank you for your support and patience!

[idkq]

Thanks to everyone who contributed to this research project. @InMatrix I feel like we missed an important section of this report which is "Where do we go from here" or next steps. Especially I would like to see the unanswered questions catalogued and discussion topics to move forward, improve and enhance Flutter's core api. There is a brief mention on complications of inner tabs on page 39 but I feel like there are a rather large number of important discussions that should take place in regards to navigation.

This is a great opportunity to compile these open questions and not let them fade out. We have a lot of expertise from the package owners who I imagine are discussing the same questions.

I don't think these questions are fully understood by anyone and require a thorough investigation. I believe they should be listed and discussed to the point where we left.

To list a few:

• What are the cases where declarative is is preferred to imperative.
• Should there be a standardized or preferred routing structure, especially for nesting.
• Missing use cases and scenarios
• Complexities around rebuilding the stack, history, back button.
• Animation and transition.
• Popups
• Navigation of Bottom Sheets

There are many other conceptual issues that need investigation. Maybe package owners can jump in and add some from what they are facing in their own issue repository or users can contribute as well.

In summary this is great chance to collect these open questions, even though we are not solving them now.

[InMatrix]

Thanks for the suggestion! I'm open to adding a future work section or expanding the limitations section in the report to acknowledge those unanswered questions. Alternatively, I'd love to see folks from the Flutter community write either an expanded response to the research report or a piece about a specific issue the research did not sufficiently consider. We can link to them from the report in the appendix.

Since this repo still has the attention of people who care about routing API in Flutter, feel free to use this space to post your thoughts and investigations about specific issues not covered by the research.

[braj065]

One thing i was looking for an answer is, that apart from beamer, vrouter and autoroute, other packages like qlevar, routemaster were also satisfying all the routing scenarios selected by the Navigator 2.0 plugin study team. Then why qlevar, routemaster weren't included in the study. The report - https://github.com/flutter/uxr/raw/master/nav2-usability/Flutter%20routing%20packages%20usability%20research%20report.pdf

[idkq]

Potential Reasons:

1 - Limited Team capacity to evaluate more packages
2 - Perhaps package owners did not show interest in participating and supporting the study
3 - Perhaps low PubDev points and likes
4 - Perhaps Did not comply at the time the study was initiated

[InMatrix]

Hi @Braj65, thank you for your question. Yes, many other routing packages exist, but we were not able to take a closer look at them for reasons @idkq mentioned. Our selection process was certainly not perfect but I hope was pragmatic. It's described in this post. To assess a package that's not covered in our research, I hope you could take a look at the "known issues" in routing API design from the report and check if the package in question has addressed them in a better way. We also identified design choices that seem to work well, and if they are adopted by the other package you're thinking about, it could be a good sign. Finally, you could try implementing the routing scenarios used in the research with the package you're evaluating and compare it with other packages' code examples.

[braj065]

Thanks @InMatrix