Hi Ember folks,
I have an idea for a possible change to the behavior of the router “loading” and “error” substates.
The routing guide describes the handling of transition promises:
modelhook … returns a promise (or if a promise was provided as an argument to
transitionTo), the transition will pause until that promise fulfills or rejects. (link)
It also describes the difference between “eager” and “lazy” transitions:
If you provide [a loading substate], you are essentially telling Ember that you want this async transition to be “eager”; [otherwise] the router will “lazily” remain on the pre-transition route while all of the destination routes’ promises resolve. (link)
That is, the router treats all promises the same, whether they were returned from a
model hook, or passed in to
transitionTo, and loading/error substates are always resolved based on the target route of the transition.
This works really well when returning a promise from a
model hook because the app can enter a very specific loading/error substate.
It doesn’t always seem to work well when passing a promise in to
transitionTo, though. When the target route and its parent “resource” route share the same model object, it’s not possible to enter the target route’s “sibling” loading state, even if the source route is also a child of that “resource” route. You must settle for the parent “resource” route’s sibling loading state.
So, what I’ve noticed about my usage is that when I provide a promise as an argument to
transitionTo(), I actually want the router to treat that as a “lazy” transition. That is, I want to stay on the source route until the promise resolves (or rejects). Staying on the source route would allow the router to resolve the loading substate (and maybe the error substate?) relative to the source route (rather than the destination route).
What do you think? Would that work better for you and your app? Worse?