Passing the state rather than the config inside events

[pauldijou]

Hey there,

When triggering events like $stateChangeStart or $stateChangeSuccess, it's the config of the state which is passed as data on the event according to here or here.

Is there a reason to pass to.self rather than to (same for from)? It seems we are only loosing infos by doing that... We can't call methods like to.is(...) or to.includes(...) (or I didn't find a way to do that).

Thanks in advance.

[ksperling]

This is primarily to support using/defining your states 'by reference'
rather than by name, e.g. if you do

var fooState = { name: 'foo', url: ... };
$stateProvider.state(fooState);

you can do stuff like
if ($state.current == fooState) ...
or
from == fooState

I'm not sure if many people really use ui-router that way though. I'm
intending to place the separate to/from etc parameters with a 'transition'
object that gets passed to event handlers and onEnter/onExit callbacks, in
which case it will be easy to support both to/from and $to/$from analogous
to $state.current and $state.$current.

Note that $state.is and $state.includes are methods on the state service,
not on the individual state objects.

On Fri, Jul 5, 2013 at 5:07 AM, Paul Dijou notifications@github.com wrote:

Hey there,

When triggering events like $stateChangeStart or $stateChangeSuccess,
it's the config of the state which is passed as data on the event according
to herehttps://github.com/angular-ui/ui-router/blob/master/src/state.js#L190or
herehttps://github.com/angular-ui/ui-router/blob/master/src/state.js#L246
.

Is there a reason to pass to.self rather than to (same for from)? It
seems we are only loosing infos by doing that... We can't call methods like
to.is(...) or to.includes(...) (or I didn't find a way to do that).

Thanks in advance.

—
Reply to this email directly or view it on GitHubhttps://github.com//issues/222
.

[pauldijou]

Thanks a lot for the quick answer! I don't really keep any reference to my states so I didn't think about it but it makes sense.

And you're right about the methods, they are in the $state object, so it's fine, my bad.

[nateabele]

@pauldijou Can this be closed or is there some other way to meet your requirements?

[pauldijou]

And closed... All fine with me, thanks.