About States

UI-Router applications behave like a state machine.

Think about each feature of an application as a set of states. Only one state can be active at one time. The user can transition from one state to another, to activate a different feature of the application.

UI-Router States

The basic building block of a UI-Router application is a UI-Router state.
A UI-Router state usually corresponds to a feature (or place) in the application in terms of the overall UI and navigation. Some examples of states might be dashboard, messages, shoppingcart, or blogentry.

A state is a javascript object which has specific properties. Those properties define the functionality of the application when that state is active.

State Properties

A name for the state, providing a way to refer to the state
How the UI will look and behave
What the browser’s URL will be
Parameter values that the state requires (such as blog-post-id)
The actual data the state requires (often fetched, asynchronously, from the backend using a parameter value)

Nested States

Unlike states in a traditional state machine, UI-Router states can be nested inside each other. A parent state can have multiple children, forming a tree of states.

Child states can be used to drill down from a more general feature to more specific one, or to implement a master/detail pattern. For instance, you might have a parent state called contacts which defines the contacts module, and renders a list of all the contacts.

Nested views

The child state’s view usually renders inside a viewport that the parent state created. This is referred to as Nested Views

Then, you might have two child states contacts.contact (to view a specific contact’s details) and contacts.new (to create a new contact). These substates share the common parent state contacts and inherit data and behavior from the parent. They are rendered inside the UI for the parent state.

State-based approach

UI-Router’s approach to applications as a tree of states encourages you to think about your application’s as a hierarchy of functionality. The tree defines the application’s functionality structure. The URL and views (i.e., the rendered tree of components in the DOM) are artifacts of the active state.

Optional Urls

Although states generally have URLs, they are optional.

You might create some child states without URLs, if it doesn’t make sense to bookmark those child states. The state machine transitions between url-less states as usual, but does not update the url when complete You still get all the other benefits of a state transition such as parameters, resolve, and lifecycle hooks.

Optional Views

Although states generally have views, they are optional.

You might create a parent state for the sole purpose of adding data or behaviors to a branch of your application.
For instance, you might create a state called admin and then child states for each administration function in your app. The parent admin state could be used to restrict access to the entire tree of child states, but provide no UI itself.


If the app’s current state is contacts and the user wants to switch to the prefs state, the UI-Router state machine creates and runs a Transition from the contacts state to the prefs state.


These transitions are essentially atomic. When transitioning from contacts to prefs, either the entire transition succeeds and the application’s current state is now prefs, or the entire transition fails and the application remains in the contacts state.


Transitions have a lifecycle, starting at Transition creation and completing with either success or failure. That lifecycle is exposed to the application developer as a set of transition hooks. The hooks allow you to tap into each stage of the Transition and cancel or alter the Transition.

To learn more about transition hooks, read the Transition section of the Guide (coming soon) and the in depth API documentation for TransitionService.