feat(state): add $stateResolved event

[timfjord]

$stateResolved fires after state resolved with possibility to prevent event.
Such functionality is useful for login system, when we need get current user first,
and then, based on response, redirect to login page or continue.

[timkindberg]

Hey I like this too!

[timkindberg]

Again you'd need to add some ngdocs for it though. Thanks!

[timfjord]

Cool. I was wating for the feedback, because i probably need to add some tests as well

[timkindberg]

Ah yes you do. I like this because it solves some other problems we were having. It's kind of like a simple short term (maybe long term) solution to this issue: #618

[marcghorayeb]

Why not just use the resolve system and check for the $stateChangeError that's fired ?
I have an ACL system that resolves the current Admin and his Roles against an ACL given in the state config. When a login is required, the resolve is rejected with a certain ERROR code that I catch in the $stateChangeError callback, which in turns redirects to a proper login page. This seems like duplicating features?

[timfjord]

I have extracted this from one of my app.
So i implemented application state, that is the parent for all other states.
application state getting current user with resolve. That's why i need to make sure i can prevent state rendering and also need to make sure that everything was resolved

[marcghorayeb]

@Timsly http://plnkr.co/edit/JwmJmj0FmXmxs7razEcd?p=catalogue
is your resolve process different ? The resolve can be set on a parent state or on a child state I guess.

[timfjord]

@marcghorayeb mine is different, but goal is the same

[nateabele]

I like the idea, but we're getting up to quite a few events here. What's the performance impact of this?

[timfjord]

@nateabele i extracted this event from my app. My goal was to wait for all resolves and than take decision either show login form and stop loading process(prevent event) or continue normal loading process.
Theoretically it can be achieved with $stateChangeError event(@marcghorayeb shared some examples) but i think resolve event should be also present and we can use it not only for login system but for some other tasks as well.

[timkindberg]

I like having a separate event, because resolving of states really is a very important "event" that takes places, and it has nothing to do with errors necessarily.

[nateabele]

After careful consideration, I've decided against this. The need for it is a symptom of $state's architecture being too large and tightly-coupled. I will attempt to break it apart and provide new interfaces over the coming weeks. Thanks again for your input and efforts on this.