Skip to content

Instantly share code, notes, and snippets.

@jasonaden
Last active February 3, 2018 00:34
Show Gist options
  • Star 0 You must be signed in to star a gist
  • Fork 0 You must be signed in to fork a gist
  • Save jasonaden/3f079e303c82672e91ac5a981fe3508f to your computer and use it in GitHub Desktop.
Save jasonaden/3f079e303c82672e91ac5a981fe3508f to your computer and use it in GitHub Desktop.
Angular Router Roadmap

Proposed Roadmap

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.

v6

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.

v6.0.0-beta.3

Bug Fixes

v6.0.0-beta.4

Bug Fixes

Features

  • AngularJsUrlSerializer for @angular/router/upgrade to make URL serialization/deserialization consistent between the two frameworks.

Deprecations

  • Deprecate DefaultUrlSerializer in favor of new AngularJsUrlSerializer (which should eventually repalce the current default).

v6.0.0-beta.5

Bug Fixes

  • Fix redirect issues that have plagued the router for a long time.

Features

v6.1

Features

v6.2

Features

New Router

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.

Design Principles

  1. Single source of truth. This is the Router State and provides configuration information as well as current navigation transition info.
  2. State is read-only and immutably updated.
  3. Use pure functions and functional composition over classes and inheritance.
  4. Expose codebase to allow easy overriding of default behavior.

Sprint 1

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.

Sprint 2

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.

Sprint 3

Create a new Recognize step to handle redirects and determining target RouteConfigs to be activated. Add new UrlParser (already developed) and new Recognize step to navigation stream and provide working sample on URL update.

Sprint 4

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).

Sprint 5

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).

Sprint 6

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.

Sprint 7

Documentation & examples.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment