Official website: router5.github.io
A simple but powerful HTML5 router, based on route-node and path-parser.
API will be subject to change, until 1.0.0 is reached. Rest assured no breaking changes will be introduced without bumping the minor version up. If you have missed something, you can look at the CHANGELOG. You can also look at the ROADMAP for planned improvements and evolutions. If you have suggestions, I'm happy to discuss them.
It is an HTML5 router, using history and organising named routes in a tree. Browser support is limited to modern browsers implementing session history: http://caniuse.com/#search=history.
Router 5 supports use of hash in URL, but session history is still required: deciding to use a hash or not is therefore not a decision based on browser support, but rather a decision based on server capabilities!
It is aimed at applications rendering a tree of components, but can easily be used elsewhere. This router is library and framework agnostic, and makes no asumption on your implementation. It favours convention over configuration, by giving you the means to observe route changes and to react to them. Afterall, why treat route changes any different than data changes?
You can read more about motivations behind it here: Why router5?.
To get started, look here: Get started
- Use of hash (#)
- Default start route: a default route to navigate to on load if the current URL doesn't match any route. Similar to
$routeProvider.otherwise()in Angular ngRoute module. - Start and stop
- Nested named routes: routes are identified by names and parameters so you don't have to manipulate URLs directly. Routes can be nested, introducing the notion of route segments.
- Route change listeners: listen to any route change, or register listeners for a specific route.
- Route node change listeners: you can add listeners to be triggered on a specific named route node. They will be triggered if that named route node is the node a component tree needs to be re-rendered from.
- Segments activation: you can control whether or not a route can be accessed by specifying a
canActivatefunction per node. Supports asynchronous results. - Segments deactivation: you can register segment components. On a route change, it will ask those components through their
canDeactivatemethod if they allow navigation. Similar to Angular 2 and Aurelia routers. Supports asynchronous results. - Transition "middleware" function: handle any data updates or other asynchronous actions before updating your view.
- Universal applications: use on client and server side
- You are in control! You decide what to do on a route change and how to do it.