Overall vision for this year with Angular Router is to: a) stabilize the router we have, and b) implement a new router to achieve treeshakability, lazy loading, and ease of use.
We want to land key features to help incentivize upgrade to v6. Additionally, there are critical bug fixes that are best suited for a major release due to the possibility of unforseen edge cases causing minor breaking changes.
- Make sure parentheses are correctly serialized/deserialized so they don't cause URL deserialization to throw errors.
- Fix Upgrade location sync so certain use cases don't cause double
NavigationStart
events to fire.
- Flatten data and params for resolvers with
paramsInheritanceStrategy = 'always'
- AngularJsUrlSerializer for
@angular/router/upgrade
to make URL serialization/deserialization consistent between the two frameworks.
- Deprecate
DefaultUrlSerializer
in favor of newAngularJsUrlSerializer
(which should eventually repalce the current default).
- Fix redirect issues that have plagued the router for a long time.
- Scroll position restoration to address a number of outstanding issues and provide a much-needed feature.
-
RouterTestingModule
to provide a way to easily set up snapshot data.
- Provide guidance and simplified API for testing route guards.
The intention in v7 is to have a new router that follows similar concepts to the current router, but to split the router into smaller pieces with fewer inter-dependencies. These will be the building blocks of the new router, and they should be built in a functional style to promote treeshakability.
- Single source of truth. This is the Router State and provides configuration information as well as current navigation transition info.
- State is read-only and immutably updated.
- Use pure functions and functional composition over classes and inheritance.
- Expose codebase to allow easy overriding of default behavior.
The first sprint should be designed to prove whether we should create this new router. The goal would be to have a RouterState
object that defines a state to activate. We should also be able to do the Activation step (render a graph of components & data from RouterState
. Activation needs to be totally separate from any other router code and should only accept the state to be activated.
Support RouteConfig
definitions and loading. They need to be immutably added to the RouterState
and should provide a mechanism for adding new configs asynchronously (so we know we can support lazy loading down the road). Also create a navigation stream so as new features are added, we can update the configuration of the stream. This will allow end to end (or manual in a browser) testing of the new router as development continues.
Create a new Recognize step to handle redirects and determining target RouteConfig
s to be activated. Add new UrlParser (already developed) and new Recognize step to navigation stream and provide working sample on URL update.
Create a history API to be more flexible than the current implementation. Should allow for adaptability to browser-based history (default) or other implementations such as tree-based (e.g. for mobile applications).
Implement a new Guards step to handle Promise and Observable based route guards. Observable guards should allow for changes in the guard's stream to immediately reflect in the navigation stream (basically, don't force observables to be completed like the current implementation).
Implement a replacement for the current router's Resolver API. Should be similar to guards in that a Promise or completed Observable would be a one-time but Observables shouldn't need to be complete, in which case new values would cause the down-stream actions to re-run.
Documentation & examples.