Parameter names confusion

[bambinoua]

Sometimes I am lost in parameter names of the package. :(

Using Navigator.push() we have RouteSettings(name: ..., arguments: ...), i.e. route path and route arguments. But this package refenrce to data, routeState, state! What is the value is need to be used for passing arguments?

Beamer.of(context).beamTo(data: ...); // Object?
Beamer.of(context).beamToReplacementNamed(routeState: ..., data: ...); // Object?, Object?
Beamer.of(context).currentBeamLocation.update(null, RouteInformation(state: ...)) // Object?

[slovnicki]

Hey @bambinoua Indeed, the naming does not translate well to the old Navigator API. I did think about this for a while, but have not pursued the idea. I hope that doc comments for those attributes explain their usage well enough, but any contributions to the docs that would explain them better is welcome.

data and routeState (which is the same as RouteInformation.state) behave differently;

• data will persist in BeamLocation until overwritten, meaning that it is available throughout the navigation within the same BeamLocation. For example, when going from /books to /books/1 and back, if data is passed in any of the beaming events, it will be available in all of those screens. This can be useful for keeping some "step count" while you go through some onboarding or similar process with multiple pages.
• routeState / RouteInformation.state is tied to the specific route and will be encoded into browser history so it can be retrieved whenever you enter that URL where the state was encoded.

[rhc]

I also had the same confusion. @slovnicki thank you for the clarification.

[slovnicki]

Glad it helped @rhc

And I just want to add that path and query parameters are specified directly in the URI that we're beaming to, e.g.

Beamer.of(context).beamToNamed('/book/1/details?sort=byName');

These are are automatically parsed and can be accessed through BeamState as pathParameters and queryParameters.

[bambinoua]

Suggestion is re-consider the code and remove redundant duplications. If we can get route state from beamState.routeInformation.state why do we need redundant routeState? If BeamState contains pathParameters, queryParameters so why uri needed if it contains duplicated information?

The BeamDelagate contains configuration and currentConfiguration. It is also confused because as for me delegate.configuration is already means that this is delegate's configuration at the moment, isn't it? If they interpreted differently, it would be good to rename ocnfiguration to something other more meaningful. If this configuration why it has type RouteInformation?

Also the comments for some methods are not changed due to breaking change. For example, method update of BeamerDelegate provides an example with state parameter but this state parameter is absent in this method.

So it's up to you. ;)

[slovnicki]

@bambinoua Good points. Unfortunately, most of these things are a bit more complex than they seem at first.

If we can get route state from beamState.routeInformation.state why do we need redundant routeState

BeamState.routeState could be removed, indeed, if we keep RouteInformation with its state as a member of BeamState instead of it being created on demand.

The BeamDelagate contains configuration and currentConfiguration

Ah, yes... This is a bit historical, I would say. It also bothered me for a long time, but I didn't revise it enough. The RouterDelegate that BeamerDelegate extends has the getter currentConfiguration that needs to be overridden and indeed does not mean the same thing as configuration, especially in the case of nested Beamers. I agree that we should think about this some more.

Also the comments for some methods are not changed due to breaking change. For example, method update of BeamerDelegate provides an example with state parameter but this state parameter is absent in this method.

Yes, comments are sometime lagging behind.

---

I will reopen this to keep reminding myself of it.