$stateChangeSuccess should expose locals

[cburgdorf]

In the Angular default routing the $routeChangeSuccess gives access to fromRoute.locals and toRoute.locals.

The locals give access to the resolved promises of the configuration block of the route.

However, with the ui-router it seems there is no way to get access to the resolved promises from the state resolve configuration block.

Am I doing it wrong? Is there another way to access those without being forced to resolve them again?

[cburgdorf]

It's a bit hacky in it's current form as it not only exposes those dependencies that where specified with the resolve block but also some internal once. I just wanted to get it started to get feedback.

[ksperling]

they're not exposed in the event currently... I suppose we could expose toLocals and fromLocals in the same way as toParams and fromParams.

I think copying the per-activation locals value onto the static state configuration object isn't ideal, especially if we don't tidy it up when the state is exited (we've also tried to stay away from writing to the configuration object as much and instead consider it to be 'owned' by the app code as opposed to by $state).

The other problem is of course that there isn't just a single set of locals per state activation, but a top level one ('globals') plus one for each view. I suppose you're interested in the top-level one in this case. They are currently available via the onEnter callback, if that helps you.

[cburgdorf]

Thank you for your answer! I updated the PR based on your feedback.

cburgdorf@e6b4fa2

1. instead of copying the locals over to the configuration object I just keep them in local variables fromResolved & toResolved (the name toLocals was already taken)
2. I changed the signature of the $stateChangeSuccess event to
   (to, toParams, toResolved, from, fromParams, fromResolved)
3. I also added them to the $routeChangeError event.

Since, I'm totally new to the ui-router I'm not fully sure how everything with nested states etc. works yet. But from my current understanding it would make sense to directly expose the top-level one instead of filtering for those which were defined in the resolve block of the specific state which might be a sub state. Because, if it is a sub state then it makes sense for it to also receive locals that where defined in the parent state.

However, because of my lack of experience for this project it might be that nothing of what I said makes any sense ;-)

I'm keen on getting this feature integrated as it's currently keeping me from moving from Angular core routing to the ui-router. I also guess it will help others who are making the switch as it smoothes the migration experiences dramatically for those who need access to the resolved promises on $routeChangeSuccess. So, if there's anything that should be changed about it, just let me know.

[cburgdorf]

I noticed I broke the build. Unfortunatly I wasn't able to run the tests locally so far as there seems to be a problem with PhantomJS. Is it assuming a global installation of PhantomJS?

[ksperling]

It does at the moment, yes. Looks like we could be using https://npmjs.org/package/phantomjs ?

[cburgdorf]

Ok, all tests green again. Should I also modify the tests to proof that the new parameter are actually working? If so, should I change this test (https://github.com/angular-ui/ui-router/blob/master/test/stateSpec.js#L120) or should I put a new one?

[cburgdorf]

I just force pushed again. I noticed that it makes much more sense to expose the whole locals object and not only locals.globals. Otherwise with nested states, you won`t get to the information you need.

[timkindberg]

Hope to accomplish this with a new $transition service

[eddiemonge]

https://gist.github.com/eddiemonge/f6a58169c2846731a1eb

[pawsong]

I access to $state.$current.locals in $stateChangeSuccess event handler.