$stateProvider.decorator won't run if state definition is declared before decorator.

[wawyed]

Because of the way state are defined, unless you define the decorator in the same angular module the state configuration is defined or you ensure that your state configuration objects are in modules that depend on the module your decorator is defined; the decorators won't get called by ui-router since those states have already been resolved.

I don't think the order of definition should affect how the decorators are run. Possibly the states should be read at run block not at config block to avoid this issue.

Plunker reproducing the issue:
http://plnkr.co/edit/C1ze61?p=preview

You can see how the decorator that it's defined in a dependant module gets called but the one that it's defined in the same module doesn't (because it was called after the state definition).

This issue is not exclusive to 0.2.12 as it was happening in 0.2.11.

[christopherthielen]

Thanks for your thoughts.

We actually switched to defer state registration until runtime in commit 838b747 (due to Type registration previously being deferred until runtime), but I reverted that change because it smelled wrong to defer everything until runtime. However, your argument for registering decorators at any time is a good one and makes me reconsider my earlier decision.

I'll have to think about this some more. I wonder if there are other use cases where you would want the states built with stateBuilder and registered at config-time.

[andreialecu]

I had an incredibly hard to track bug in my app because of this with ui-router-extras.

I had my modules defined like this:

var app = angular.module('app', [  'ct.ui.router.extras.dsr',
  'ct.ui.router.extras.sticky', 'app.submodule']);

I was then configuring routes on app.submodule. This was not properly running the decorator, and thus $$state wouldn't be added to the states, resulting in toState.$$state is not a function errors.

Explicitly adding 'ct.ui.router.extras.dsr', 'ct.ui.router.extras.sticky' as deps of app.submodule solved the problem in this case.

[crhistianramirez]

I'm running into this issue but setting the main module as a dependency for my submodule doesn't seem to be doing the trick. My app is defined like this:

// app.js
var app = angular.module('app', ['submodule1', 'submodule2']);

//submodule.js
var submodule = angular.module('submodule1', []);

Tried to update it to:

// app.js
var app = angular.module('app', ['submodule1', 'submodule2']);

//submodule.js
var submodule = angular.module('submodule1', ['app']);

I even tried this, but this won't register any states in submodule1:

// app.js
var app = angular.module('app', [ 'submodule2']);

//submodule.js
var submodule = angular.module('submodule1', ['app']);

Any ideas?

[stale]

This issue has been automatically marked as stale because it has not had
recent activity. It will be closed if no further activity occurs.

This does not mean that the issue is invalid. Valid issues
may be reopened.

Thank you for your contributions.