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.

The name of an angular 1.5+ .component() (or directive with
bindToController and/or scope declaration) which will be used for this view.

Resolve data can be provided to the component via the component's bindings object (for 1.3+ directives, the
bindToController is used; for other directives, the scope declaration is used). For each binding declared
on the component, any resolve with the same name is set on the component's controller instance. The binding
is provided to the component as a one-time-binding. In general, components should likewise declare their
input bindings as one-way ("<").

This is an injectable provider function which returns the name of the component to use.
The provider will invoked during a Transition in which the view's state is entered.
The provider is called after the resolve data is fetched.

This is an injectable provider function which returns the actual controller function, or the name
of a registered controller. The provider will invoked during a Transition in which the view's state is
entered. The provider is called after the resolve data is fetched.

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.

The lazyLoad function is invoked before the state is activated.
The transition waits while the code is loading.

The function should load the code that is required to activate the state.
For example, it may load a component class, or some service code.
The function must retur a promise which resolves when loading is complete.

For example, this code lazy loads a service before the abc state is activated:

The abcService file is imported and loaded
(it is assumed that the abcService file knows how to register itself as a service).

Lifecycle

The lazyLoad function is invoked if a transition is going to enter the state.

The function is invoked before the transition starts (using an onBefore transition hook).

The function is only invoked once; while the lazyLoad function is loading code, it will not be invoked again.
For example, if the user double clicks a ui-sref, lazyLoad is only invoked once even though there were two transition attempts.
Instead, the existing lazy load promise is re-used.

When the promise resolves successfully, the lazyLoad property is deleted from the state declaration.

If the promise resolves to a LazyLoadResult which has an array of states, those states are registered.

The original transition is retried (this time without the lazyLoad property present).

If the lazyLoad function fails, then the transition also fails.
The failed transition (and the lazyLoad function) could potentially be retried by the user.

Lazy loading state definitions (Future States)

State definitions can also be lazy loaded.
This might be desirable when building large, multi-module applications.

To lazy load state definitions, a Future State should be registered as a placeholder.
When the state definitions are lazy loaded, the Future State is deregistered.

A future state can act as a placeholder for a single state, or for an entire module of states and substates.
A future state should have:

A name which ends in .**.
A future state's name property acts as a wildcard Glob.
It matches any state name that starts with the name (including child states that are not yet loaded).

A url prefix.
A future state's url property acts as a wildcard.
UI-Router matches all paths that begin with the url.
It effectively appends .* to the internal regular expression.
When the prefix matches, the future state will begin loading.

A lazyLoad function.
This function should should return a Promise to lazy load the code for one or more StateDeclaration objects.
It should return a LazyLoadResult.
Generally, one of the lazy loaded states should have the same name as the future state.
The new state will then replace the future state placeholder in the registry.

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.

If the return value is a promise, the promise is waited for, then the resolved async value is processed using the same rules.

Note: redirectTo is processed as an onStart hook, before LAZY resolves.
If your redirect function relies on resolve data, get the Transition.injector and get a
promise for the resolve data using UIInjector.getAsync.

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 may be used in views, transition hooks or other resolves that belong to this state.
The data may also be used in any views or resolves that belong to nested states.

As an array

Example:

The user resolve injects the current Transition and the UserService (using its token, which is a string).
The [[ResolvableLiteral.resolvePolicy]] sets how the resolve is processed.
The user data, fetched asynchronously, can then be used in a view.

Note: You cannot specify a policy for each Resolvable, nor can you use non-string
tokens when using the object style resolve: block.

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 during the Transition have their resolves fetched.
States that are "retained" do not have their resolves re-fetched.

If you are currently in a parent state parent and are transitioning to a child state parent.child, the
previously resolved data for state parent can be injected into parent.child without delay.

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

Because of this scoping and lifecycle, 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:

Views (the components which fill a ui-view tag)

Transition Hooks

Other resolves (a resolve may depend on asynchronous data from a different resolve)

Injecting other things into resolves

Resolve functions usually have dependencies on some other API(s).
The dependencies are usually declared and injected into the resolve function.
A common pattern is to inject a custom service such as UserService.
The resolve then delegates to a service method, such as UserService.list();

Special injectable tokens

UIRouter: The UIRouter instance which has references to all the UI-Router services.

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

'$transition$': A string alias for the Transition injectable

'$state$': For onEnter/onExit/onRetain, the state being entered/exited/retained.

Other resolve tokens: A 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] }
}

View name anchored to a state

Example:

targets the <div ui-view='foo'></div> which was created in a view owned by the state bar.baz

views: {
'foo@bar.baz': {...}
}

Absolute addressing

You can address a ui-view absolutely, using dotted notation, by prefixing the address with a !.
Dotted addresses traverse the hierarchy of ui-views active in the DOM:

Example:

absolutely targets the <div ui-view='nested'></div>
... which was created in the unnamed/$default root <ui-view></ui-view>

views: {
'!$default.nested': {...}
}

Relative addressing

Absolute addressing is actually relative addressing, 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:
The ui-view is targeted relative to the anchored state by traversing the nested ui-view names.

Example:

targets the <div ui-view='bar'></div>
... which was created inside the
<div ui-view='foo'></div>
... which was created inside the parent state's template.

views: {
'foo.bar': {...}
}

Example:

targets the <div ui-view='bar'></div>
... which was created in <div ui-view='foo'></div>
... which was created in a template from the state baz.qux

views: {
'foo.bar@baz.qux': {...}
}

Example:

a view can relatively target a named ui-view defined on an ancestor using ^ (meaning "parent")

For additional in-depth details about how ui-view addressing works, see the internal api [[ViewService.match]].

State template+controller and views: incompatiblity

If a state has a views object, any state-level view properties (Ng1ViewDeclaration) are 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. The state declaration must not have any of the following fields: