Why pass arguments in Flutter route strings?

user_650894 0
Viewed 424

The popular Fluro package for Flutter allows devs to pass arguments between Flutter pages via the route string. For example:

collection/289/item/1224?view=grid

Why are people doing this? There are a number of disadvantages of this approach relative to passing arguments via objects:

  • You lose compile-time type enforcement for all arguments that aren't ultimately strings. You have to typecast somewhere.
  • You have to reference objects by ID and look them up by ID instead of just getting the object directly. You have to manage unique IDs for objects that wouldn't otherwise have them, and you may need to also cache remotely loaded objects so they're not reloaded on page change.

I can think of the following possible advantages of passing all arguments via the route:

  • If Flutter eventually supports Android's ability to kill and restart an app in the background, the app could restart on the same page merely by knowing the route. The Flutter team may decide to use the route for this purpose.
  • If you plan to share code between mobile and web versions of your app, by making each mobile page stateless, you're better positioned for doing so.

Neither of these advantages is realized today. The Flutter team has not decided how to restart Android apps (to my knowledge), and Flutter Web is still too buggy and slow for production.

So why are people actually passing arguments via the route? Why are people using packages such as Fluro? Is it just for potential future benefit, or are they realizing benefit now?

(I'm trying to plan how I should structure my own apps.)

flutter routes
2 Answers

I think that this question largely misses a large part of the routing equation, namely, deep links.

When you're routing inside and app (internal navigation) it definitely makes sense to pass an object around. The next version of Fluro will support this approach.

However, if you're interacting with an external source like a web link, url scheme, etc, then there are times when it's not desirable or favourable to have to construct an object. It's also common for APIs to contain urls to resources such as (https://my.api/products/55).

For cases like this, having wildcard or named parameter matching is pretty darn useful.

user_3534630

Fluro prioritizes deeplinking, this benefit is fully realized when you have a web app that has a set of routes you can replicate in Flutter. Then, if someone has the app installed but visits the website on their phone, you can forward them to the app seamlessly.

Also, in large apps the simple route arguments force you to use a performant repository pattern so you're not relying on passing models around your routes. This is generally a better way to write apps so it has a side benefit of enforcing a modern and performant architecture.

That said, like any technology decision, it has pros and cons. If your particular use case does not align with Fluro, it's not necessarily that Fluro is bad, it's that your needs do not align with it.

Another package that I have yet to investigate is auto_route, I suspect it would benefit projects that decide to not use fluro

user_11303420
Related