abstract-state-router travis-ci npm

Like ui-router, but without all the Angular. The best way to structure a single-page webapp.

ui-router is fantastic, and I would use it in all of my projects if it wasn’t tied to AngularJS.

But I don’t want to use AngularJS - I want to use [my favorite templating/dom manipulation libraries here].

Thus, this library! Written to work with browserify, it lets you create nested “states” that correspond to different parts of the url path.

If you’ve never used AngularJS’s ui-router before, check out this post: Why your webapp needs a state-based router.

To see an example app implemented with a couple of different browser rendering libraries, click here to visit the state-router-example on Github Pages.

If you have any questions, ask me on Gitter! Join the chat at https://gitter.im/TehShrike/abstract-state-router

Current renderer implementations

If you want to use the state router with some other templating/dom manipulation library, read these docs! It’s not too bad to get started.


Using npm + your favorite CommonJS bundler is easiest.

npm install abstract-state-router

You can also download the stand-alone build from wzrd.in. If you include it in a <script> tag, a abstractStateRouter function will be included on the global scope.

Want to use the abstract-state-router without messing with bundlers or package managers? Check out the minimum-viable-project code (in a single HTML file!) over at the simplest-abstract-state-router-usage.


var createStateRouter = require('abstract-state-router')

var stateRouter = createStateRouter(makeRenderer, rootElement, options)

The makeRenderer should be a function that returns an object with four properties: render, destroy, getChildElement, and reset. Documentation is here - see test/support/renderer-mock.js for an example implementation.

The rootElement is the element where the first-generation states will be created.


Possible properties of the options object are:

  • pathPrefix defaults to '#'. If you’re using HTML5 routing/pushState, you’ll most likely want to set this to an empty string.
  • router defaults to an instance of a hash brown router. The abstract-state-router unit tests use the hash brown router stub. To use pushState, pass in a hash brown router created with sausage-router.
  • throwOnError defaults to true, because you get way better stack traces in Chrome when you throw than if you console.log(err) or emit 'error' events. The unit tests disable this.

stateRouter.addState({name, route, defaultChild, data, template, resolve, activate, querystringParameters, defaultQuerystringParameters})

The addState function takes a single object of options. All of them are optional, unless stated otherwise.

name is parsed in the same way as ui-router’s dot notation, so ‘contacts.list’ is a child state of ‘contacts’. Required.

route is an express-style url string that is parsed with a fork of path-to-regexp. If the state is a child state, this route string will be concatenated to the route string of its parent (e.g. if ‘contacts’ state has route ‘:user/contacts’ and ‘contacts.list’ has a route of ‘/list’, you could visit the child state by browsing to ‘/tehshrike/contacts/list’).

defaultChild is a string (or a function that returns a string) of the default child’s name. If you attempt to go directly to a state that has a default child, you will be directed to the default child. (For example, you could set ‘list’ to be the default child of ‘contacts’. Then doing state.go('contacts') will actually do state.go('contacts.list'). Likewise, browsing to ‘/tehshrike/contacts’ would bring you to ‘/tehshrike/contacts/list’.)

data is an object that can hold whatever you want - it will be passed in to the resolve and activate functions.

template is a template string/object/whatever to be interpreted by the render function. Required.

resolve is a function called when the selected state begins to be transitioned to, allowing you to accomplish the same objective as you would with ui-router’s resolve.

activate is a function called when the state is made active - the equivalent of the AngularJS controller to the ui-router.

querystringParameters is an array of query string parameters that will be watched by this state.

defaultQuerystringParameters is an object whose properties should correspond to parameters defined in the querystringParameters option. Whatever values you supply here will be used as the defaults in case the url does not contain any value for that parameter.

resolve(data, parameters, callback(err, content).redirect(stateName, [stateParameters]))

The first argument is the data object you passed to the addState call. The second argument is an object containing the parameters that were parsed out of the route and the query string.

If you call callback(err, content) with a truthy err value, the state change will be cancelled and the previous state will remain active.

If you call callback.redirect(stateName, [stateParameters]), the state router will begin transitioning to that state instead. The current destination will never become active, and will not show up in the browser history.


The activate function is called when the state becomes active. It is passed an event emitter named context with four properties:

  • domApi: the DOM API returned by the renderer
  • data: the data object given to the addState call
  • parameters: the route/querystring parameters
  • content: the object passed into the resolveFunction’s callback

The context object is also an event emitter that emits a 'destroy' event when the state is being transitioned away from. You should listen to this event to clean up any workers that may be ongoing.

addState examples

	name: 'app',
	data: {},
	route: '/app',
	template: '',
	defaultChild: 'tab1',
	resolve: function(data, parameters, cb) {
		// Sync or asnyc stuff; just call the callback when you're done
		isLoggedIn(function(err, isLoggedIn) {
			cb(err, isLoggedIn)
	}, activate: function(context) {
		// Normally, you would set data in your favorite view library
		var isLoggedIn = context.content
		var ele = document.getElementById('status')
		ele.innerText = isLoggedIn ? 'Logged In!' : 'Logged Out!'

	name: 'app.tab1',
	data: {},
	route: '/tab_1',
	template: '',
	resolve: function(data, parameters, cb) {
	}, activate: function(context) {
		document.getElementById('tab').innerText = context.content

		var intervalId = setInterval(function() {
			document.getElementById('tab').innerText = 'MORE CONTENT!'
		}, 1000)

		context.on('destroy', function() {

	name: 'app.tab2',
	data: {},
	route: '/tab_2',
	template: '',
	resolve: function(data, parameters, cb) {
	}, activate: function(context) {
		document.getElementById('tab').innerText = context.content

stateRouter.go(stateName, [stateParameters, [options]])

Browses to the given state, with the current parameters. Changes the url to match.

The options object currently supports just one option “replace” - if it is truthy, the current state is replaced in the url history.

If a state change is triggered during a state transition, and the DOM hasn’t been manipulated yet, then the current state change is discarded, and the new one replaces it. Otherwise, it is queued and applied once the current state change is done.

If stateName is null, the current state is used as the destination.

// This actually redirects to app.tab1, because the app state has the default child: 'tab1'

stateRouter.evaluateCurrentRoute(fallbackStateName, [fallbackStateParameters])

You’ll want to call this once you’ve added all your initial states. It causes the current path to be evaluated, and will activate the current state. If the current path doesn’t match the route of any available states, the browser gets sent to the fallback state provided.


stateRouter.stateIsActive(stateName, [stateParameters])

Returns true if stateName is the current active state, or an ancestor of the current active state…

…And all of the properties of stateParameters match the current state parameter values.

// Current state name: app.tab1
// Current parameters: { fancy: 'yes', thing: 'hello' }
stateRouter.stateIsActive('app.tab1', { fancy: 'yes' }) // => true
stateRouter.stateIsActive('app.tab1', { fancy: 'no' }) // => false
stateRouter.stateIsActive('app') // => true

stateRouter.makePath(stateName, [stateParameters], options)

Returns a path to the state, starting with an optional octothorpe #, suitable for inserting straight into the href attribute of a link.

The options object supports one property: inherit - if true, querystring parameters are inherited from the current state. Defaults to false.

If stateName is null, the current state is used.

stateRouter.makePath('app.tab2', { pants: 'no' })


These are all emitted on the state router object.

State change

  • stateChangeAttempt(functionThatBeginsTheStateChange) - used by the state transition manager, probably not useful to anyone else at the moment
  • stateChangeStart(state, parameters) - emitted after the state name and parameters have been validated
  • stateChangeCancelled(err) - emitted if a redirect is issued in a resolve function
  • stateChangeEnd(state, parameters) - after all activate functions are called
  • stateChangeError(err) - emitted if an error occurs while trying to navigate to a new state - including if you try to navigate to a state that doesn’t exist
  • stateError(err) - emitted if an error occurs in an activation function, or somewhere else that doesn’t directly interfere with changing states. Should probably be combined with stateChangeError at some point since they’re not that different?
  • routeNotFound(route, parameters) - emitted if the user or some errant code changes the location hash to a route that does not have any states associated with it. If you have a generic “not found” page you want to redirect people to, you can do so like this:
stateRouter.on('routeNotFound', function(route, parameters) {
	stateRouter.go('not-found', {
		route: route,
		parameters: parameters

DOM API interactions

  • beforeCreateState({state, content, parameters})
  • afterCreateState({state, domApi, content, parameters})
  • beforeResetState({state, domApi, content, parameters})
  • afterResetState({state, domApi, content, parameters})
  • beforeDestroyState({state, domApi})
  • afterDestroyState({state})


To run the unit tests:

  • clone this repository
  • run npm install
  • run npm test

Automated browser testing provided by Browserstack.

Tested in Chrome, Firefox, Safari, and IE10+ (IE9 doesn’t support replace).

Build Status

State change flow

  • emit stateChangeStart
  • call all resolve functions
  • resolve functions return
  • destroy the contexts of all “destroy” and “change” states
  • destroy appropriate dom elements
  • reset “change”ing dom elements
  • call render functions for “create”ed states
  • call all activate functions
  • emit stateChangeEnd

Every state change does this to states

  • destroy: states that are no longer active at all. The contexts are destroyed, and the DOM elements are destroyed.
  • change: states that remain around, but with different parameter values - the DOM sticks around, but the contexts are destroyed and resolve/activate are called again.
  • create: states that weren’t active at all before. The DOM elements are rendered, and resolve/activate are called.

HTML5/pushState routing

pushState routing is technically supported. To use it, pass in an options object with a router hash-brown-router constructed with a sausage-router, and then set the pathPrefix option to an empty string.

var makeStateRouter = require('abstract-state-router')
var sausage = require('sausage-router')
var makeRouter = require('hash-brown-router')

var stateRouter = makeStateRouter(makeRenderer, rootElement, {
	pathPrefix: '',
	router: makeRouter(sausage())

However to use it in the real world, there are two things you probably want to do:

Intercept link clicks

To get all the benefits of navigating around nested states, you’ll need to intercept every click on a link and block the link navigation, calling go(path) on the sausage-router instead.

You would need to add these click handlers whenever a state change happened.

server-side rendering

You would also need to be able to render the correct HTML on the server-side.

For this to even possible, your chosen rendering library needs to be able to work on the server-side to generate static HTML. I know at least Ractive.js and Riot support this.

The abstract-state-router would need to be changed to supply the list of nested DOM API objects for your chosen renderer.

Then to generate the static HTML for the current route, you would create an abstract-state-router, tell it to navigate to that route, collect all the nested DOM API objects, render them as HTML strings, embedding the children inside of the parents.

You would probably also want to send the client the data that was returned by the resolve functions, so that when the JavaScript app code started running the abstract-state-router on the client-side, it wouldn’t hit the server to fetch all the data that had already been fetched on the server to generate the original HTML.

Who’s adding this?

Track development progress in #48.

It could be added by me, but probably not in the near future, since I will mostly be using this for form-heavy business apps where generating static HTML isn’t any benefit.

If I use the abstract-state-router on an app where I want to support clients without JS, then I’ll start working through those tasks in the issue above.

If anyone else has need of this functionality and wants to get keep making progress on it, I’d be happy to help. Stop by the chat room to ask any questions.




Related Repositories



Like ui-router, but without all the Angular. The best way to structure a single-page webapp. ...



Hacker News written in Knockout using abstract-state-router ...



Like ui-router, but without all the Angular. The best way to structure a single-page webapp. ...

Top Contributors

TehShrike ArtskydJ greenkeeperio-bot daytonlowell m59peacemaker crissdev


-   v5.13.0 zip tar
-   v5.12.5 zip tar
-   v5.12.4 zip tar
-   v5.12.3 zip tar
-   v5.12.2 zip tar
-   v5.12.1 zip tar
-   v5.12.0 zip tar
-   v5.11.0 zip tar
-   v5.10.0 zip tar
-   v5.9.0 zip tar
-   v5.8.1 zip tar
-   v5.8.0 zip tar
-   v5.7.1 zip tar
-   v5.7.0 zip tar
-   v5.6.0 zip tar
-   v5.5.0 zip tar
-   v5.4.0 zip tar
-   v5.3.0 zip tar
-   v5.2.0 zip tar
-   v5.1.1 zip tar
-   v5.1.0 zip tar
-   v5.0.2 zip tar
-   v5.0.1 zip tar
-   v5.0.0 zip tar
-   v4.1.0 zip tar
-   v4.0.0 zip tar
-   v3.6.1 zip tar
-   v3.6.0 zip tar
-   v3.5.1 zip tar
-   v3.5.0 zip tar