EmberJS Loading Substate: What logic does it use to climb the route hierarchy to find the loading template?

2
votes

I'm trying to wrap my head around Ember's loading substate. According to the Guides...

http://emberjs.com/guides/routing/loading-and-error-substates/

...the loading substate will show while the model is being resolved, and if a loading template doesn't exist for the current route, it will climb the route hierarchy until it finds a 'loading' template. So I defined a 'loading' template, but it doesn't always show.

Here an example:

http://emberjs.jsbin.com/junop/2

First, when the page loads, the loading template doesn't show even when the ApplicationRoute's model is being resolved. Then if you go to 'books', the loading template will show. So going from 'index' to 'books' will always show the loading template. But them going to a specific 'book' (e.g. Three Little Pigs in my example) doesn't show the loading template. Finally, going to 'book' from 'books' doesn't show the loading template, even though it will if you go from 'index' to 'books'. I can't make sense of all of this. What logic does Ember use to climb the hierarchy to show the loading template?

1
templatesember.jspromise

1 Answers

4
votes

There are two different things related to loading. The loading route vs the loading action.

Each resource with at least one child (the root included, aka application route) has a loading route. Ember won't hit the loading route unless the parent resource has already been rendered. This means it's less useful for the first load, and more useful for transitions.

http://jsbin.com/cajivava/5/edit

No worry, there are loading actions! Each time a model hook is taking some time to resolve, it will send an action to that route, which will traverse up the router until handeled (or if you handle it, then return true, which will send it up the tree). This can be super useful for magical loading, or for first time loads. Just remember (and I show it in this example, that if you don't handle the loading action at a particular route it will be passed up to application).

http://jsbin.com/cajivava/6/edit

Now you can just hack it into a different place in the application route, since it's a special route that's only ever loaded once. A mixture of the two is usually the best plan if you have a long loading app in the beginning.

http://jsbin.com/cajivava/4/edit

It's easiest to think about transitions in the sense of the outlets. The section to be rendered is stalled, so the outlet where it's going to rendered into, transitions to the loading route. Once it's complete, it navigates to books index.

In the example below, try clicking on cows. It's a resource 2 deep and books resolves immediately (the resource in the middle), but the transition is stalled on cows, so our outlet where we're going to render all of the newness transitions to the loading route.

http://jsbin.com/buyaxipowi/1/edit

Individual loading routes housed in their own resource require the resource itself to be resolved before you can hit it's loading route:

http://jsbin.com/niwerikuli/1/edit