Roadmap

Where is this project headed?

The goal is to eventually convince the angular core team to merge UI-Router into Angular core (perhaps 2.0?). The Angular team has expressed interest and will be taking a look at the project sometime soon.

Here are some of the larger items that the ui-router team has on our roughly sketched out roadmap:

• Factor out/rewrite 'resolve' logic into a $resolve service that handles (1) inheritance from parent resolve(s) (2) dependencies within a single resolve
• Have a separate $view service for defining what goes into ui-view tags. Will support an async interface along the lines of $view.load('myview', { template: ..., controller: ..., resolve: ... }), but will also need to support a synchronous interface that $state can use after having called $resolve itself (so that all views relating to a state can be updated atomically). One major conceptual difficulty is that the naming of nested views (how they get turned into "qualified" names) is fairly intrinsically linked to the state hierarchy.
• parameter handling needs to be revisited, to support reload=false per parameter and two-way binding between $stateParams and $location for those.
• nice things like $state.sref() / related directives
• support for independent "components" (re-usable state tree branches) with their own states that can be instantiated multiple times in the global (or a parent component) state hierarchy (see #123)
• Add parameter sharing when transitioning from one state to another, so that any parameters that are shared between the two states will be defaulted from the current $stateParams (however this won't apply to parameters that are named the same "by coincidence" to avoid unintended behaviours).
• implement $injector.bind() that binds injectable parameters via Function.prototype.bind and returns a plain function object, so that for callbacks like in $urlRouter or $state we don't have to either (1) use $injector.invoke() where 95% of use cases would prefer a simple callback with 1 parameter (which is also orders of magnitudes faster in performance critical code paths) or (2) force the 5% to contort their configuration logic into custom providers just so they can get at the necessary services they want to use inside the callbacks. I'm intending to do this one as a PR on core.