$state injection into resolve function gives old state

[kevinsbennett]

When passing in $state into a resolve function, it seems to provide the old state, not the new state that we're resolving for.

resolve: {
model: ["$state", function($state){
//$state.current gives info for old state here
}]
}

This is a problem as we can't access custom state data in the resolve function.

[ksperling]

It's a little tricky... $state is a service, so there really is only one $state.

We also can't really update $state.current before the resolve process starts, because (1) it's asynchronous, so the state hasn't changed yet, and (2) it could fail.

I'm thinking a nice way to solve this would be to have a special injectable like '$transition' which would be the transition object for the current transition, with properties like 'to', 'from', 'toParams', 'fromParams', ...

[nateabele]

Yeah, 👍. The $transition service could be mirrored to that encapsulation inside transitionTo() that we talked about.

[ksperling]

Yeah, i think the 3rd parameter to transitionTo becomes the transition object

This seems like a design flaw that does make rather common use cases virtually impossible. If my route includes a page parameter, and that route's resolve map needs to pull up that "page" of data from my API, it has no way of obtaining this information without parsing location.hash itself--at which point I might as well not be using any framework's router.

I understand the timing issues involved, but this strikes me as a fairly huge hole in the system.

[laurelnaiad]

@oncomeme -- can't you access the parameter directly in your resolve, instead of seeking it out in the $state service? Or am I misunderstanding?

[romario333]

@oncomeme - as @stu-salsbury mentioned, you can inject $stateParams into the resolve function. That seems to be working just ok.

It works. It's also really awkward and makes it impossible to define a truly standalone service as it has to be baby fed by everything that wants to use it.

[nateabele]

I believe the phrase is "patches are welcome".

[ksperling]

URL parameters of a state are parameters of a state. As such I would consider it bad design (essentially a layering violation) for a service to access these directly. A state-level 'resolve' that passes correct parameters to the correct service is the way to go.

[ProLoser]

Be careful about naming conventions as $transition is used inside of ui-bootstrap and may get picked up by animation code in the core.

[ksperling]

@ProLoser I've been thinking there should be a naming convention for "local" magical values that are injectable, that makes them easily distinguishable from global services. Maybe $transition$, i.e. starting and ending with $.

[nateabele]

@ksperling I've been thinking, what if, instead of a separate service, we just overwrote $state.transition and gave it a more robust API (i.e. never make it null, and add some getters for status & to/from)?

[timkindberg]

@nateabele that makes sense to me. The $transition service idea felt like it could get more complicated for users. Also keeps the transition object "namespaced" on $state, so we'll avoid the naming convention issues @ProLoser mentioned (which obviously is your goal). I like it.