Ember 1.11 breaks rendering in the application route?

[digitalcora]

This JSbin is a minimal example of the problem. Note that in the application route's beforeModel, it immediately renders a "loading" template, which is later replaced with the index route's template once its model resolves (I used an artificial delay to make this obvious). Note also this is using Ember 1.10.

Now replace 1.10 with 1.11 in the script tags. The app throws an error that this.connections is undefined. Searching for this error led me to #10372, but the only helpful suggestion there was "don't use render outside of renderTemplate or action handlers", and it's not clear how I could achieve the same result otherwise (the new application_loading substate seems broken, or at least I can't get it to work at all under Ember-CLI). At any rate, if that suggestion were accurate this would seem to be a major breaking change, but there is nothing mentioned about it in the changelog, and the general expectation is that minor releases are backwards compatible.

[xtian]

Does this workaround work for you? http://jsbin.com/pujekeniro/2/edit

I don't think ApplicationRoute is supposed to be able to enter the loading state. There's a test to verify that:

ember.js/packages/ember/tests/routing/substates_test.js

Line 195 in 90397ef

QUnit.test("Slow promises returned from ApplicationRoute#model don't enter LoadingRoute", function() {

[digitalcora]

Oops, I shouldn't have named that template loading – it is named something different in our actual app, and I forgot about the route auto-generation thing. In fact we cannot have a loading route, because we do not want the "eager transition" behavior of the loading state.

This might be a better example: http://emberjs.jsbin.com/pasagusobe/1/edit?html,js,output

Basically we have an app where certain routes have models that take a long time to load. Since we are not using loading substates, on first-load you see nothing but a blank white page for many seconds while the model resolves. Ideally this first-load process would have a loading indicator. Of course this wouldn't work with hard-coded route transitions, as in your example, because we need it to work for arbitrary routes.

[xtian]

Why aren't you able to use loading states? If the model is in memory (after the first load) the loading state won't be triggered.

[digitalcora]

My understanding is that if we had a top-level loading state, it would be eagerly transitioned-into at the start of every route transition (or at least, every transition that needs to fetch some data). Our client does not want this behavior – they want the contents of the previous route to remain visible and interactable until the destination route resolves.

We are already handling this with a flag on the application controller that is set and cleared by the loading and didTransition actions on the application route, and a loading indicator in the application template that displays if the flag is true. This doesn't work for the initial app load, because the application template has not been rendered yet.

[xtian]

What about something like this then? http://emberjs.jsbin.com/doqawofimu/3/edit

[digitalcora]

That looks promising, I'll have to try it in the real app once I get a chance. I had thought the loading action was purely "informational" and didn't realize it could modify the default behavior.

About the original issue, are you in a position to comment on the regression? Workarounds aside, minor releases usually don't break things along these lines. Is this a case where "it never should have worked"? The docs hint at this:

render is used both during the entry phase of routing (via the renderTemplate hook) and later in response to user interaction

...but this is rather vague and doesn't say the method can only be used in those circumstances (and in fact, prior to Ember 1.11 it could be used elsewhere). Plus there are evidently no assertions to check this.

[xtian]

Yeah, I'm not sure whether your usage of Route#render is supported or not. I'd assume not, but I've never used it outside of the renderTemplate hook.

In any case, looks like it may have broken when the internals were changed here: e047a91

[digitalcora]

Thanks @xtian, your suggestion worked in the real app! I still would like to be able to get the mythical application_loading substate working in Ember-CLI, but that's a separate issue. I will close this one.

Regarding the cryptic error I got initially, do you think it's worth adding an assert in the render code to handle this case, and better explain the limitations of the method?

[discorick]

@Grantovich were you ever able to get the application_loading substate working ? I am having the same trouble rendering into a specific application outlet.

[digitalcora]

@discorick I haven't looked into it recently, since @xtian's suggestion was sufficient for my use case. If you're trying to use render outside of renderTemplate or an action handler, it appears that's not supported anymore and you'll have to find a workaround. If you are using render in one of those circumstances, you are probably encountering an unrelated issue.

[discorick]

@Grantovich thanks that clears things up - I guess I will need to find a workaround.

[sandstrom]

@Grantovich It's still open, feel free to close if this is resolved (as you mentioned).

@discorick Loading route/sub-state for the ApplicationRoute seems to be disabled by design

[digitalcora]

@sandstrom Right, my particular issue is resolved so I'll close this. It could be the application_loading problems are resolved in 1.13 anyway, I haven't been able to check yet.