Upgrading from YUI 3.4.x

A beta version of Router was first introduced in YUI 3.4.0, but was named Controller. If you're using Controller in YUI 3.4.0 or 3.4.1, you'll need to make the following changes to your code when upgrading:

• The name of the class has changed from `Controller` to `Router`. Change all references to the `Controller` class and the `controller` module in your code to refer to the `Router` class and `router` module, respectively. To ease migration, `Controller` is now an alias for `Router` and will still work, but this alias will be removed in a future release of YUI.

• The `html5`, `root`, and `route` properties are now attributes. If you were accessing them as properties, update your code to access them as attributes instead. For example, `var root = myController.root;` becomes `var root = myRouter.get('root');`, and `myController.root = '/foo';` becomes `myRouter.set('root', '/foo');`.

• The function signature for route handlers has changed. Previously, the second argument passed to all route handlers was the `next()` function. As of YUI 3.5.0, the second argument is a response object, and the third argument is the `next()` function. To preserve backwards compatibility, the response object is also a function that will call `next()`, but you should still update your code to take the new argument order into account.

  Note: As of YUI 3.13.0, the response object is no longer callable, use the `next()` function passed as the thrid argument to route handlers.

URL-based Routing on the Client?

You bet! URLs are an excellent way to maintain state in a web app, since they're easy to read, easy to change, and can be bookmarked and shared.

Server-side web frameworks use URLs to maintain state by routing them to different pages and by storing information in query strings. These same techniques can now be used by client-side web apps to achieve better parity with server-side logic and to provide a more seamless user experience.

Router allows you to define routes that map to callback functions. Whenever the user navigates to a URL that matches a route you've defined, that route's callback function is executed and can update the UI, make Ajax requests, or perform any other necessary actions. See [[#Routing]] for more details on how this works.

Often you'll want to change the URL in order to trigger a route handler, perhaps because the user has taken an action that should change the state of your application. Router provides a `save()` method that sets a new URL and saves it to the user's browser history. There's also a `replace()` method to replace the current URL in the user's browser history without creating a new entry. The [[#Updating the URL]] section describes these methods in detail.

Sample URLs

In browsers that support the HTML5 history API, Router generates real URLs that can gracefully degrade to allow server-side handling of initial pageviews or pageviews without JS enabled. Most modern browsers (including recent versions of Firefox, Chrome, Safari, and Mobile Safari) support HTML5 history.

In browsers that don't support the HTML5 history API, Router falls back on using the location hash to store URL information and trigger history changes. This mostly applies only to older browsers and Internet Explorer. Unfortunately, even Internet Explorer 9 doesn't support the HTML5 history API.

The table below contains examples of the kinds of URLs Router might generate when the `save()` method is called on a Router instance, starting from an initial URL of `http://example.com/`.

Using Router

Instantiating Router

To begin adding route handlers, the first thing you'll need to do is create a new Router instance.

This is the simplest way of working with Router, but you may also extend `Y.Router` to create a custom Router class that suits your needs. The [[#Extending `Y.Router`]] section explains how to do this.

Config Attributes

When instantiating Router, you may optionally pass in a config object containing values for any of the following attributes. For more details on these attributes, see Router's API docs.

Here's an example that sets all the configurable attributes at instantiation time:

Setting the Root Path

Let's say the URL for your website is `http://example.com/mysite/`. Since Router matches routes based on the URL path, it would look for routes beginning with `/mysite/`.

You could deal with this by ensuring that all your routes start with `/mysite/`, but that's tedious, and it won't work well if you're writing a component that might be used on various sites where you can't anticipate the root path.

This is where the `root` config attribute comes in. If you set `root` to `'/mysite'`, then all routes will be evaluated relative to that root path, as illustrated below.

Note: The `root` must be an absolute path.

The `root` path also acts a mount point for the router and will only consider paths that fall under the `root` (when set). The following example demonstrates these semantics:

Extending `Y.Router`

While `Y.Router` may be instantiated and used directly, you might find it more convenient to extend the `Y.Router` class to create a subclass customized for your particular needs.

Use the `Y.Base.create()` method to extend `Y.Router` and add or override prototype and static members and attributes. You may also optionally specify one or more Base extensions to mix into your new class.

One benefit of extending `Y.Router` is that you can easily add default routes and route handlers to your custom Router class, and they'll be shared by all instances of that class unless overridden at the instance level:

Now all instances of `Y.CustomRouter` will inherit all the custom defaults and can add to or override them. The `router` instance created here will handle the `/` and `/pie` routes in addition to its own `/cheesecake` route, and will evaluate all routes from the `/mysite` root path.

Routing

Use the `route()` method to add a new route to a Router instance. The first parameter is a path specification or regular expression that the URL path must match, or alternatively a route object. The remaining parameters are callback functions, function names, or arrays of either to execute (middleware) when the route is matched.

Routes are always evaluated in the order they're added. The first route that matches a given URL is executed, and any subsequent routes that also match the URL will not be executed unless the first route passes control to the next callback (middleware) or route. See [[#Chaining Routes and Middleware]] for more info on executing more than one route callback for a given URL.

When a route callback is specified as a string instead of a function, it's assumed to represent the name of a function on the Router instance.

As an alternative to using the `route()` method, routes may be added at instantiation time using the `routes` config attribute:

This is functionally equivalent to adding the routes via the `route()` method, except that it will replace any default routes, and the routes are added during the Router's initialization stage rather than after.

Paths, Placeholders, and RegExps

A route path may be specified as either a string or a regular expression. When a string is provided, it's compiled to a regular expression internally. If the regex matches the path portion (not including protocol, domain, query string, etc.) of a URL being dispatched, the route callback will be executed.

Path strings may contain placeholders. When a route is matched, the values of these placeholders will be made available to the route callback on the `req.params` object.

A placeholder prefixed by a `:`, like `:pie`, will match any character except for a path separator (`/`).

A placeholder prefixed by a `*`, like `*path`, will match as many characters as it can until the next character after the placeholder, including path separators.

Use `*` all by itself as a wildcard to match any path at all:

Wildcards can also be used within a path:

Placeholder names may contain any character in the range `[A-Za-z0-9_-]` (so `:foo-bar` is a valid placeholder but `:foo bar` is not).

When a regular expression is used as a path specification, `req.params` will be an array. The first item in the array is the entire matched string, and subsequent items are captured subpattern matches (if any).

Route Objects

Alternatively, instead of specifying only a route's path, entire route objects can be specified when calling Router's `route()` method. These route objects are the same as those specified as [[#Config Attributes]] and what Router uses for its internal storage of its routes.

Using route objects to specify routes allows for greater interoperability between routing system and allows for a place to attach metadata for a route. Two examples are adding a `name` property to routes to give them a logical name, or getting fully-processed route data from the server or another Router instance.

The following example shows how to add extra metadata to routes by using route objects:

Route Callbacks

When a route is matched, the callback functions associated with that route will be executed, and will receive three parameters:

`req` (Object)

An object that contains information about the request that triggered the route. It contains the following properties:

`params` (Object or Array)

Parameters matched by the route path specification.

If a string path was used and contained named parameters, then `params` will be a hash with parameter names as keys and the matched substrings as values. If a regex path was used, `params` will be an array of matches starting at index `0` for the full string matched, then `1` for the first subpattern match, and so on.

`path` (String)

The current URL path matched by the route.

`pendingCallbacks` (Number)

Number of remaining callbacks the route handler has after this one in the dispatch chain.

`pendingRoutes` (Number)

Number of matching routes after the current route in the dispatch chain.

`query` (Object)

Hash of query string parameters and values specified in the URL, if any.

`route` (Object)

Reference to the current route object whose callbacks are being dispatched.

`router` (Object)

Reference to this router instnace.

`src` (String)

What initiated the dispatch.

In an HTML5 browser, when the back/forward buttons are used, this property will have a value of "popstate". When the `dispath()` method is called, the `src` will be `"dispatch"`.

`url` (String)

The full URL.

`res` (Object)

An object that contains methods and information that relate to responding to a request.

The response object contains the following properties (it will eventually contain more, and may be augmented by subclasses or used to pass information from route to route):

`req` (Object)

Reference to the request object.

`next` (Function)

A function to pass control to the next callback or the next matching route if no more callbacks (middleware) exist for the current route handler. If you don't call this function, then no further callbacks or route handlers will be executed, even if there are more that match. If you do call this function, then the next callback (if any) or matching route handler (if any) will be called. All of these functions will receive the same `req` and `res` objects that were passed to this route (so you can use these objects to pass data along to subsequent callbacks and routes).

`err` (String)

Optional error which will stop the dispatch chaining for this `req`, unless the value is `"route"`, which is special cased to jump skip past any callbacks for the current route and pass control the next route handler.

Inside a route callback, the `this` keyword will always refer to the Router instance that executed that route.

Router Params

Usually it's desirable to define routes using string paths because doing so results in easily readable routes and named request parameters. When route params require specific validation or formatting there's a tendency to rewrite a string-based route path as a regular expression. Instead of switching to more complex regex-based routes, route param handlers can be registered to validate more complex routes.

A common example of route param validation and formatting is resource `id`s which should be a number and formatted as such (instead of a string). The following registers a param handler for `id` and it will always make sure it's a number:

Now any routes registered that use the `:id` parameter will have that value validated and formatted using the above function.

The above first validates and formats the original value of the `:id` placeholder from the URL (in this case the string `"10"`) by passing it to the registered `id` param handler function. That function returns the number `10` which is then assigned to `req.params.id` before the route handler is called.

Route param handlers can also be defined as regular expressions. Regex param handlers will have their `exec()` called with the param value parsed from the URL, and the resulting matches object/array (or `null`) will become the new param value. The following defines regex for `username` which will match alphanumeric and underscore characters:

If a param handler regex or function returns a value of `false`, `null`, `undefined`, or `NaN`, the current route will not match and be skipped. All other return values will be used in place of the original param value parsed from the URL.

The following defines two additional routes, one for `"/users/:username"`, and a catch-all route which will be called when none of the other routes match:

The last two `router.save()` calls above skip the main posts and users route handlers because the param values parsed from the URL fail validation of the `id` and `username` param handlers. When a param value fails validation, that route is skipped, and in this case the catch-all `"*"` route handler is called.

A router's param handlers are also accessible through its `params` attribute and can be set, in bulk, at init time or to reset all existing param handlers. The above param handlers could have been registered via the `params` attribute:

This is functionally equivalent to adding the param handlers via the `param()` method, except that it will replace any default params, and the params are added during the Router's initialization stage rather than after.

Chaining Routes and Middleware

By default, only the first route that matches a URL will be executed, even if there are several routes that match. Similarly, if a route has multiple callbacks (i.e. middleware), only the first callback will be executed by default. However, when a route is executed, it will receive a `next()` function as its third parameter. Calling this function will execute either the next callback (if any) for that route or the next matching route (if any).

If you want the first route callback to pass some data along to subsequent callbacks, you can attach that data to either the `req` object or the `res` object, which are shared between all callbacks and routes that are executed during a single request.

In the following example, both middleware and multiple routes are used. The `handleFlavor` middleware function is executed first, and the `flavor` data it adds to the `req` is passed along to every route callback.

Whether to store data on `req` or `res` is up to you, but by convention, data pertaining to the request should be stored on `req`, and data pertaining to a response or to some other result of that request should be stored on `res`.

Route-based middleware provides the ability to specify an arbitrary number of callbacks per route. This enables you to break down the logic of handling a request into distinct parts that can be reused with multiple routes. Middleware can be specified in a very flexible manner, and it can be grouped in arrays of arbitrary depth. Consider the following example:

For a less contrived usage, checkout the GitHub Contributors example app which uses middleware for its advanced routing.

Updating the URL

Call the `save()` or `replace()` methods to update the URL and store an entry in the browser's history.

The only difference between the two is that `save()` saves a new history entry, while `replace()` replaces the current history entry.

Changing the URL in this way will trigger a dispatch, and will execute the first route that matches the new URL (if any). A dispatch will also be triggered automatically whenever the user uses the browser's back or forward buttons.

When you need to provide state information to your route handlers, it's best to provide that information as query parameters in the URL. This way, your application's state is always reflected in the current URL, and can be properly restored when a URL is bookmarked or copied.

Capturing Link Clicks

An excellent way to provide progressive enhancement on a page with URLs that can be handled by both the server and the client is to use normal links, and then add a delegated event handler to capture clicks on those links and use client-side routing when JavaScript is available. You can also use this technique to selectively use client-side routing or server-side routing depending on which link is clicked.

Now a click on any link, such as `Click me!`, will automatically be handled by the router if there's a matching route. If there's no matching route, or if the user doesn't have JavaScript enabled, the link click will be handled normally by the browser.

To Dispatch or Not to Dispatch?

Dispatching is what it's called when Router looks for routes that match the current URL and then executes the callback of the first matching route (if any).

A dispatch can be triggered in the following ways:

• Automatically, whenever the URL changes after the initial pageview.
• Manually, by calling the `dispatch()` method.
• Manually (but only in HTML5 browsers), by calling the `upgrade()` method when the URL contains a hash-based route that was copied from a legacy browser.

It's important to remember that if a user bookmarks or copies an HTML5 URL generated by Router and visits that URL later, the full URL will be sent to the server. On the other hand, if a user bookmarks or copies a hash-based URL in a legacy browser and then visits it later, the hash portion of the URL won't be sent to the server.

For instance, let's say a user visits your website at `http://example.com/`. On that page, you have the following code:

In an HTML5 browser, when the user clicks the button, Router will change the URL to `http://example.com/pie` and then execute the `/pie` route, but the browser won't contact the server. If the user bookmarks this URL and then loads it again later, the web server will handle the request. If it doesn't recognize the path `/pie`, it may return a 404 error, which would be no good.

In a legacy browser, clicking the button will cause the URL to change to `http://example.com/#/pie`, and the `/pie` route will be executed, also without contacting the server. The difference is that if the user bookmarks this URL and loads it later, the hash portion won't be sent to the server. The server will only see `http://example.com/`, so it will be necessary to handle the request on the client as well.

There are two ways to deal with this. One way would be to implement server-side logic to handle requests for `/pie` and render the appropriate page. To provide fallback support for hash-based URLs, we can modify the client-side code to call the `dispatch()` method in legacy browsers, by adding the following:

The benefit of this is that HTML5 URLs will be rendered on the server and won't present any difficulties for search crawlers or users with JS disabled. Meanwhile, hash-based URLs will be handled on the client as long as JS is enabled. The drawback with this method is that it may require maintaining duplicate logic on both the server and the client.

The other way to handle this would be to configure the server to render the same initial page for all URLs (it would essentially route all paths to the same page), and always dispatch on the client, regardless of the browser's capabilities:

On the one hand, this solution avoids most of the server-side complexity and keeps all the router logic on the client. On the other, it requires the client to support JavaScript, so it won't play well with search crawlers that can't run JavaScript or users who disable JavaScript.

Best Practices

HTML5 URLs vs. Hash URLs

As discussed in [[#To Dispatch or Not to Dispatch?]], there are benefits and drawbacks to both HTML5 URLs—that is, URLs generated via the HTML5 history API—and hash-based URLs. This adds difficulty to any client-side URL-based routing solution, and unfortunately it means you may need to make some tough choices about the architecture of your application.

The primary benefit of HTML5 URLs is that they can potentially be handled on the server as well as on the client. This has potential benefits for application architecture (rendering an initial pageview on the server is often faster than rendering it on the client) and for preventing link rot (if you rewrite or replace your application at some point, it's relatively easy to set up server-side redirects to point the old URLs to a new location). That said, HTML5 URLs may require more server-side logic in order to work correctly.

Hash-based URLs, on the other hand, can't be handled on the server because browsers don't send the hash portion of a URL to a server. This means they must always be rendered on the client using JavaScript. Even worse, if you eventually rewrite or replace your web app, it's extremely unlikely that you'll be able to keep that old JavaScript around just for the sake of redirecting old URLs, which means any old hash-based URLs in the wild are likely to stop working.

In general, the benefits of HTML5 URLs tend to outweigh the drawbacks when compared to hash-based URLs, which is why Router automatically defaults to using HTML5 URLs in browsers that support it. The hash-based URLs generated by Router should be used only as a fallback for legacy browsers.

Cross-browser URL Compatibility

It's very important that any URL generated by Router be usable in any browser. If a user of a legacy browser copies a URL and shares it with a friend who uses an HTML5 browser, that URL should still work. And if someone copies an HTML5 URL and shares it with a user of a legacy browser, that needs to work too.

When a hash-based URL is loaded in an HTML5 browser and `dispatch()` or `upgrade()` are called, Router automatically upgrades the URL to an HTML5 URL. So a URL like `http://example.com/#/pie` will become `http://example.com/pie`, and the HTML5 browser will execute the appropriate route handler.

The difference between the `dispatch()` and `upgrade()` methods is that `dispatch()` always dispatches to the first route that matches the current URL, whereas `upgrade()` will only dispatch if the browser is an HTML5 browser and the URL is a legacy hash-based URL that must be handled on the client in order to upgrade it to an HTML5 URL.

When an HTML5 URL like `http://example.com/pie` is loaded in a legacy browser, what happens depends on how your server is configured:

• If the server is capable of handling the URL, then it should render the page in the appropriate state, and Router won't need to do anything.

• If the server is not capable of handling the URL, then it should render the initial page state and you should call Router's `dispatch()` method. Router will parse the HTML5 URL and execute the appropriate route, even in a legacy browser.

For more on how dispatching works, see [[#To Dispatch or Not to Dispatch?]].

Progressive Enhancement and SEO

In general, HTML5 URLs that can be rendered by the server when necessary provide the best support for both progressive enhancement (by rendering initial pageviews more quickly, even in browsers with JavaScript disabled) and for search engine optimization (by allowing you to use real, non hash-based URLs that can be crawled by search bots, which may not support JavaScript).

Being able to render the same application states both on the server and the client may require you to write duplicate code. However, if you use JavaScript on the server, and in particular if you use Node.js, you may be able to share code.

Router's routing style and route specification format are intentionally very similar to those of the Express.js server-side framework. With a little care, you may be able to use the same route handler code on both the server and the client.

Supporting Google's Ajax Crawling Scheme

One of the problems with the hash-based URLs Router uses to support legacy browsers is that most search engines don't distinguish between a URL with a hash fragment and one without. This means that, to a search bot, the URLs `http://example.com/` and `http://example.com/#/pie` might look the same, even though they might represent completely different content in your application.

Google's Ajax Crawling Scheme specifies a way to make hash-based URLs crawlable by the GoogleBot if you're willing to implement some extra server-side logic.

To indicate to the GoogleBot that your hash URLs are crawlable, the hash must be prefixed by `#!` instead of the default `#`. You can make Router do this automatically by setting the value of the static `Y.HistoryHash.hashPrefix` property before initializing any Router instances:

Next, read Google's getting started guide for a description of how the Ajax crawling scheme works and the additional changes you'll need to make to your application. Most of the changes you'll need to make will have to happen in your server-side logic.

Don't skip the server-side changes! Without them, using the `#!` prefix won't do you any good, and may even hurt the search ranking of your pages.

Known Limitations

• HTML5 history is not supported by Internet Explorer 9 or lower. IE10 is the first version of Internet Explorer that supports HTML5 history. Earlier versions will fall back to hash-based history by default.

• Android 2.x is forced to use hash-based history due to a bug in Android's HTML5 history implementation. This bug does not affect Android 3.0 and higher.

• Hash-based URLs are case-insensitive in Internet Explorer 8 and 9. Most browsers follow the HTML5 spec and treat URLs—including hash-based URLs—as case-sensitive. IE8 and IE9 ignore case in hash-based URLs, so changing a hash-based URL from `/foo` to `/Foo` won't trigger a dispatch.

• Internet Explorer 6 and 7 only retain the most recent hash-based URL from a previous pageview after navigating to another page and returning. However, history entries created within a single pageview will persist for the duration of that pageview, and bookmarked URLs will still work in all cases.

• In Internet Explorer 6 and 7, the page titles displayed for history entries in the browser's history dropdown menu are not correct. Instead of showing the title of each page, it shows part of the URL of each page.

• Internet Explorer (all versions) replaces the current history entry when the hash portion of the URL is manually edited in the URL bar instead of adding a new history entry as other browsers do. There's unfortunately nothing YUI can do to detect or work around this.