You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
This is a work in progress proposal and will be updated with implementation details
For more details about where this is coming from, visit v2 Roadmap Discussion or v2 Roadmap Wiki.
This issue will be separated into multiple issues when implementation details become clearer;
BeamState as a notifier by default
Typed beam parameters
Motivation
The goal of Router API was to have declarative routing which is guided by state instead of imperative calls. But, in practice, most developers want completely imperative routing and some scenarios require it. Beamer can be used in both ways, where simple imperative API (Beamer.beamTo*) is default, but we have the ability to create our own states whose change will guide the beaming. We will keep the current imperative high-level API, but will rework the internals slightly so the changes on BeamStates guide beaming directly, instead of BeamState being (by default) just a collection of current routing parameters. Another thing that would be nice to have is strong types on the routing parameter, such as being able to declare that the :id in route should be an integer.
The text was updated successfully, but these errors were encountered:
This is a work in progress proposal and will be updated with implementation details
For more details about where this is coming from, visit v2 Roadmap Discussion or v2 Roadmap Wiki.
This issue will be separated into multiple issues when implementation details become clearer;
BeamState
as a notifier by defaultMotivation
The goal of Router API was to have declarative routing which is guided by state instead of imperative calls. But, in practice, most developers want completely imperative routing and some scenarios require it. Beamer can be used in both ways, where simple imperative API (
Beamer.beamTo*
) is default, but we have the ability to create our own states whose change will guide the beaming. We will keep the current imperative high-level API, but will rework the internals slightly so the changes onBeamState
s guide beaming directly, instead ofBeamState
being (by default) just a collection of current routing parameters. Another thing that would be nice to have is strong types on the routing parameter, such as being able to declare that the:id
in route should be an integer.The text was updated successfully, but these errors were encountered: