Request: way to list registered routes

[daniel-v]

Use case

Whenever I start the server, I'd like to log the list of registered routes. They tend not to change when I run my app, we can think of it as constant. This would allow me to print debug info during development and a way to verify changes in endpoints a CI script can use to verify changes post-deploy.

Current situation

Currently, Router has no way to allow access to added/mounted routes.

@sealed
class Router {
  final List<RouterEntry> _routes = [];

Proposal

A method or public function that can return an immutable list of RouterEntries. Something along these lines:

UnmodifiableListView<PrintableRouterEntry> getRoutes(Router router) {
  return UnmodifiableListView(router._routes.map((r) => PrintableRouterEntry(r)));
}

class PrintableRouterEntry {
  /* ... */
}

[jonasfj]

Uh, yeah, I think this could be a cool feature.

Maybe we can just make it static function like: Router.inspect(myRouter) -> Iterable<Route> (or something like that).

This would make even more sense if we allowed for bits of meta-data to attached to individual routes. Like whether or not it's part of the public API.

---

I'm not exactly sure how we would design this though..

[daniel-v]

With the turmoil around mirrors, I'd keep this simple. Another aspect I'd consider is that it should be AOT compilable.

Some folks use built in webserver in their Flutter apps to serve stuff for their webview. I use AOT+Docker on BE. (startup time matters).

I think, a simple solution now, that just gives me what I need, the routes, is preferred over designing a complex system. Later, we can always introduce a RouterInspector class which accepts a list of annotations to consider without breaking backward compatibility.

[isoos]

The underlying data could be also used to collect route-specific statistics.

[daniel-v]

Q to those participating in the thread, if I submitted a PR with a minimal set of changes that I need, what are the chances that it would eventually land in a release? (I have CLA signed already)

I'd be happy to go back and forth to make sure that I do not introduce an API that would/will be used by a more complex system proposed in the thread too.

edit: I suppose at least I could express what I had in mind in a more specific way that could help triage.