Express' Router for the Browser
The Express Router is great! It is reliable and really simple. With Express 5.0 the router module was pulled out into a stand-alone package, so I figured, why not see if it runs in the browser. Sure enough, it did! So this is a wrapper around the Express Router package that layers on browser push state based location updates. I was heavily influenced by Page.js and use a very similar method to transparently catch page changes events.
NOTE: Requires HTML5 history
api, aka pushState
. This module does not support hash based routing.
Usage
$ npm install --save nighthawk
browser.js
:
var Nighthawk = // Create your routervar router = // Register your routesrouterrouter router
Setting A Base Path
Nighthawk supports service applications that are not hosted at the root of your domain via base
. To set a base path just pass it in to
the router constructor. For example:
var Nighthawk = var router = base: '/foo' // Optionally you can also set the base path// with `router.base('/foo')`. routerrouter
If have routes which match your base path but require full server rendered page refreshes, you
can use the reloadOnUnhandled
option to have Nighthawk force the browser to reload from the server with the new
route when the final handler is hit. By setting this option to true, the final handler will force the browser to
reload the page from the server via window.location = <new url>
.
Parsing Querystring's
Nighthawk can setup querystirng parsing for you, just pass the desired parsing funciton as queryParser
. For example:
var router = queryParser: parse // Or for extended parsing like in express queryParser: parse;
Note: The parseQuerystring
option is deprecated as of 2.1.0
, and will be removed in 3.0.0
.
Listen Options
There are a few options you can pass to the listen
call:
popstate
: Whenfalse
, Nighthawk will not listen forpopstate
eventsinterceptClicks
: Whenfalse
, Nighthawk will not listen for linkclick
eventsdispatch
: Whenfalse
, Nighthawk will not process the initial route on listen
Manually change url and run middleware stack
In case you have some event on the page which is not a normal link click or popstate, you can
call router.changeRoute('/your/url')
, and the Nighthawk instance will run the route processing.
This is helpful for things like form submissions and actions which should prompt users to login.
history
is not supported?
What happens when It just falls back to basic HTML link behavior. Thats the great thing about this pattern, it builds on top of basic building blocks of the web. Also, if it is not supported, your route will still run, so you can still use Nighthawk to kick off your application in unsupported browsers.
Why use Nighthawk?
Unlike some other recent front-end routing libraries (react-router, angular-ui-router & ember router) 1, this package requires no special integration points into your links and no special methods to call to change routes. It layers transparently over your existing application and catches link clicks which cause route changes.
But I have to learn a new library!! No you dont. This library directly uses the Express router, so if you know Express you already know Nighthawk. All
the middleware patterns you know from Express on the server are valid with Nighthawk. If you load data on the backend with a middleware, you can can use
a module like nets
to re-use the same middleware on the front-end.
Nighthawk is also relatively small, weighing in at 19kb minified and gzipped. If you are using browserify you are probably already bundling modules like buffer
and url
, so if you don't count those we only add 9kb total. This is a fair bit smaller than other comparable libraries for front-end routing. You
can see for yourself by running npm run size
, which will open a breakdown of where the file size comes from and display some file size stats.
Run the examples
$ npm run example-basic
$ npm run example-basedir
$ npm run example-redirect
Visit http://localhost:1234.
Tests
$ npm test
[1]: In opinionated frameworks this is not really that big of a deal because you are already tied down to an ecosystem that probably works really well. But in a "pick your own adventure" style application it is much nicer to have less coupling.