When using a component declaration (component: MyComponent), each input binding for the component is supplied
data from a resolve of the same name, by default. You may supply data from a different resolve name by mapping it here.

Each key in this object is the name of one of the component's input bindings.
Each value is the name of the resolve that should be provided to that binding.

Any component bindings that are omitted from this map get the default behavior of mapping to a resolve of the
same name.

This is a spot for you to store inherited state metadata.
Child states' data object will prototypally inherit from their parent state.

This is a good spot to put metadata such as requiresAuth.

Note: because prototypal inheritance is used, changes to parent data objects reflect in the child data objects.
Care should be taken if you are using hasOwnProperty on the data object.
Properties from parent objects will return false for hasOwnProperty.

An object which optionally configures parameters declared in the url, or defines additional non-url
parameters. For each parameter being configured, add a ParamDeclaration keyed to the name of the parameter.

Resolve - a mechanism to asynchronously fetch data, participating in the Transition lifecycle

Resolve - a mechanism to asynchronously fetch data, participating in the Transition lifecycle

The resolve: property defines data (or other dependencies) to be fetched asynchronously when the state
is being entered. After the data is fetched, it can be used in views, transition hooks or other resolves
that belong to this state, or to any views or resolves that belong to nested states.

Lifecycle

Since a resolve function can return a promise, the router will delay entering the state until the promises
are ready. If any of the promises are rejected, the Transition is aborted with an Error.

By default, resolves for a state are fetched just before that state is entered. Note that only states
which are being entered have their resolves fetched. States that are "retained" do not have their resolves
re-fetched. If you are currently in a parent state A and are transitioning to a child state A.B, the
previously resolved data for state A can be injected into A.B without delay.

Any resolved data for A.B is retained until A.B is exited, e.g., by transitioning back to the parent state A.

Because of this, resolves are a great place to fetch your application's primary data.

Injecting resolves into other things

During a transition, Resolve data can be injected into:

ui-view Controllers

TemplateProviders and ControllerProviders

Other resolves

Injecting other things into resolves

Since resolve functions are injected, a common pattern is to inject a custom service such as UserService
and delegate to a custom service method, such as UserService.list();

Angular 1

An Angular 1 resolve function can inject some special values:

$transition$: The current Transition object; information and API about the current transition, such as
"to" and "from" State Parameters and transition options.

Other resolves: This resolve can depend on another resolve, either from the same state, or from any parent state.

$stateParams: (deprecated) The parameters for the current state (Note: these parameter values are

Angular 2

An Angular 2 resolve function can inject some special values:

Transition: The current Transition object; information and API about the current transition, such as
"to" and "from" State Parameters and transition options.

Other resolves: This resolve can depend on another resolve, either from the same state, or from any parent state.

example

// Injecting a resolve into another resolve
resolve: [
// Define a resolve 'allusers' which delegates to the UserService.list()// which returns a promise (async) for all the users
{ provide: 'allusers', useFactory: (UserService) => UserService.list(), deps: [UserService] },
// Define a resolve 'user' which depends on the allusers resolve.// This resolve function is not called until 'allusers' is ready.
{ provide: 'user', (allusers, trans) => _.find(allusers, trans.params().userId, deps: ['allusers', Transition] }
}

// Targets named ui-view="header" in the template of the ancestor state 'top'// and the named `ui-view="body" from the parent state's template.
views: {
'header@top': MsgHeaderComponent,
'body': MessagesComponent
}

View targeting details

There are a few styles of view addressing/targeting. The most common is a simple ui-view name

Relative addressing

Absolute addressing is actually relative addressing, only anchored to the unnamed root state. You can also use
relative addressing anchored to any state, in order to target a target deeply nested ui-views:

example

// target the `<div ui-view='bar'></div>`... which was created inside the// `<div ui-view='bar'></div>`... which was created inside the parent state's template.
views: { 'foo.bar': {...} }

example

```js

// target the <div ui-view='bar'></div>... which was created in
// <div ui-view='foo'></div>... which was created in a template crom the state baz.qux
views: { 'foo.bar@baz.qux': {...} }

State component: and views: incompatiblity

If a state has a views object, the state-level component: property is ignored. Therefore,
if any view for a state is declared in the views object, then all of the state's views must be defined in
the views object.