emberjs/ember.js — pull request #3655 by machty (2013-10-27 23:55:08+00:00)
Title: [FEATURE ember-routing-loading-error-substates] Named substate entry

This PR augments substate behavior in a few ways:

1) `loading` actions don't stop bubbling at the pivot route and will
continue bubbling up the route hierarchy; this doesn't change the
behavior whereby loading substates won't be entered if they're
above the pivot route, but rather just fixes the odd behavior
of you not being able to catch `loading` actions on higher level
routes.
2) When looking for an appropriate substate to enter, the router will
first try and find a loading substate sibling with the name of
router that the error/loading action emanated from, e.g. if `foo`
route returns a slow promise and both `foo_loading` and `loading`
routers have been defined (via route class or template), the
`foo_loading` substate will be preferred and entered over plain ol'
`loading`, whereas a slow promise from 'bar' route would enter
the more generalized 'loading' route (assuming 'bar_loading' route
wasn't defined)
3) Top-level error/loading substates can now be entered. They are
top-level, which means they get rendered as siblings to
ApplicationView vs within ApplicationView's outlet. This
handles slow/rejecting promises returned from `ApplicationRoute`.
If a route class/template corresponding to 'application_error'
or 'application_loading' is found, it will be entered. This
may seem like a special-casing of the substate naming conventions,
but is actually consistent with the useful rule established in
(2) above: Ember will say "ok, slow/rejecting promise came from
the 'application' route, let's check if a specifically named
'error' or 'loading' substate exists for it and enter it if so".
The only special-casing is that it won't go to the second step
of generalizing and looking for routes named specifically
'loading'/'error' to enter, since that corresponds to child
substates of the internal this.resource('application')

This may or may not make sense to merge into beta but I wanted to
get some eyes on it before making a decision. If we decide this
doesn't belong in beta, I can add a new feature flag around the
behavior in (2) and (3), but (1) should definitely make its
way into beta.