I totally agree with @hansbak . That's really important to have in order to improve the support for the web.

The way I saw other packages implementing this is by incorporating default named routes into the package (for example the vrouter package). This works, but I think it adds unnecessary parser logic and complicates things (especially for apps that are only for iOS and Android).

What I think it's a better solution though would be to add as an optional implementation for those that want either named parameters and/or web support in a way that maintains the context.flow<T>().update or context.flow<T>().complete calls the same and changed only the onGenerateRoute by adding something like a URL parser that returned the flow state data.

For example (extending from the example in the documentation):

FlowBuilder<Profile>(
  state: const Profile(),
  onGeneratePages: (profile, pages) {
    return [
      PathMaterialPage<void>(
        child: NameForm(),
        path: '/',
        stateFromPath: (Map<String, dynamic> arguments) => profile,
      ),
      if (profile.name != null) PathMaterialPage(
        child: AgeForm()
        path: '/profile/:name',
        stateFromPath: (Map<String, dynamic> arguments) => profile.copyWith(name: arguments['name']),
      ),
    ];
  },
);

ps: In this case, PathMaterialPage would extend MaterialPage, and those two attributes (path and stateFromPath) would be added to ensure that the page can be accessed by the user if it goes directly to the URL /profile/Luca for example.

I would love to hear your thoughts and please tell me if there's something I wasn't clear on.

Uh oh!

url paths? #20

Description

Metadata

Metadata

Assignees

Labels

Projects

Milestone

Relationships

Development

Issue actions