Should fastboot execute code scheduled for 'afterRender' queue?

[Gaurav0]

Code scheduled for the afterRender queue (i.e. run.schedule('afterRender')) expects the DOM to be rendered. Is it intended that fastboot run such code?

Unfortunately or otherwise, people have been moving code from didInsertElement to afterRender queue in order to avoid a performance deprecation warning.

[mixonic]

The afterRender queue could have a number of uses. I don't think we should stop it from running in Fastboot. Is there a specific use-case or issue motivating this issue @Gaurav0? There isn't a lot of detail here.

[Gaurav0]

@mixonic I'm seeing a lot of code in the wild, and several third party addons I'm including (ivy-codemirror, ember-cli-jstree), following this advice:

emberjs/ember.js#12290 (comment)

It doesn't help that the advice provided here:

http://emberjs.com/deprecations/v1.x/#toc_modifying-a-property-within-code-didinsertelement-code

usually doesn't work.

[mixonic]

@Gaurav0 if it plans to interact with the DOM, that code should schedule from didInsertElement, not init.

I don't believe there is justification to drop afterRender entirely here. Perhaps some docs can be tweaked.

[Gaurav0]

Turn it around. The question is, is there ever a use case for afterRender in fastboot, when it isn't supposed to run unless DOM has been rendered?

[mixonic]

Yes. I'm using it to make Ember Wormhole compatible with Ember FastBoot in yapplabs/ember-wormhole#54. It is un hack for sure, but dropping afterRender simply b/c we don't have a bevvy of use-cases for it today seems short-sighted. I can imagine a world where we execute all hooks on FastBoot components, but skip on queue where DOM work should be scheduled. This would be a major departure from the current strategy though.

[Gaurav0]

Alright. I'm going to point this at the learning team then.

[djsegal]

@mixonic can you look at Ember-Swiper/ember-cli-swiper#21?

I think it's one of the use cases @Gaurav0 was talking about