How come parent routes don’t render until their child routes models have resolved?
It seems like in this fiddle the application’s header could render straight away, as soon as it is ready. As it would on a traditional website. But it doesn’t. This feels like it should be the default behaviour. It would certainly improve the perceived performance and reduce the ‘white screen’ problem, which is amplified by Ember’s large file size.
I’m sure there are technical reasons for it being like this. I’d love to know more about why. I dug into the Router source and Outlets, but I’m none the wiser.
It just depends on how “blocking” you are in the routes model hook. If you wait until each route’s model returns a promise you will block forever as you mentioned. In modern apps I fire off an ajax request async (not blocking) and return an empty array (or object). When that returns right away that means I paint right away -when the async code resolves I populate the array and let ember’s 2WDB update the view
@amk I don’t really know much about the decisions behind the way it works. I just want to clarify what you’re talking about.
Ember does what you expect when a loading template is defined, right? And you are suggesting that it work the same way without a loading template? What would you have Ember render in the {{outlet}} when there is no loading template?
Well, no - no it doesn’t do what I’d expect Considering all the talk about perceived performance.
Does my jsfiddle make sense to you? The point is simple really… why doesn’t the route render ‘progressively’ by default as a traditional web page would. You have to include blank loading routes for the desired effect.
I genuinely don’t understand how nobody else seems to be talking about this
