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.
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
- 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
- The actual data the state requires (often fetched, asynchronously, from the backend using a parameter value)
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.
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)
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
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.
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.
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.
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
the UI-Router state machine creates and runs a Transition from the
contacts state to the
These transitions are essentially atomic.
When transitioning from
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
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.