Route Life Cycle

John Lindquist: Let's talk about the life-cycle of changing a route. We're on the root URL here. We just loaded up this app template, which is simply an h1 with a changeRoute.

When we click on that changeRoute, it's going to fire up this changeRoute. That's going to change the location to /new. That'll take us here, load up the new template after the promises have resolved. We just have this promise waiting for two seconds and it'll resolve with an object passing along a message.

Then we'll show how it goes through this routeChangeStart and routeChangeSuccess.

Step one is going to be before we even start the route change. Step two is when it starts. Step three is when it's successfully changed and step four is when the new controller has been instantiated.

If I go ahead and click on this, you can see that nothing has really happened here. I just want to show that the path hasn't changed. We're at a point where if you want to do something before the path changes, here's your chance. You're not going to get another one.

We'll continue on. You can see now that we're at the routeChangeStart, the path has changed so you're too late if you want to do something before the path has changed.

Now, you can see, we have current and previous objects we can inspect from the routeChangeStart event. The current means we're going to the current one, which is going to be this new route with the new controller. It's mapped to that resolve, waiting for that promise.

The previous actually has very similar things, the template URL, the controller. It has something called locals with a template and a scope, and everything. The reason those are different is because this hasn't been set up yet for the routeChangeSuccess.

If we play through this, we waited two seconds. You can see that now on the current, we'll have something called locals.

Now we have a loadData object which is with the message of success, because that is this object here, which is mapped to loadData here. That's why it's called loadData.

We have a template which has been loaded and parsed from this template URL. Now, it's ready to go into the part where it'll instantiate the new controller.

But if you look back here, you can see that the template hasn't rendered yet. Everything hasn't been fired up and changed visually.

We're at a point before that happens, but the route has successfully changed. It's prepared to do what it does next, which is going to be a cradle of stuff. We're going to inject loadData and template. If I run this again, you can see that loadData is ready because it was done on that locals, and the template is ready if you wanted to see that for any reason.

Basically, that's how it walks through before you change it. That's really your only chance before the path changes. Once it starts up, that's before any of the promises have been resolved. It knows where it's going, it knows where it's come from, but it doesn't have anything ready to instantiate the new controller.

When it's successfully changed, then that's your point before the UI is updated, it has everything ready. Once that's done it'll jump down here and instantiate the controller, and the process is done. So that's the life-cycle of a route changing.