Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Use -in-element to render at appropriate time #37

Merged
merged 7 commits into from
Sep 19, 2017

Conversation

rondale-sc
Copy link
Contributor

@rondale-sc rondale-sc commented Aug 3, 2017

This PR attempts to address the fact that in ember-cli-head's initializer we call component.appendTo(document.head). This triggers a rendering cycle where Glimmer fully processes the head-layout component and then appends it to the document head before the application's main rendering process.


We decided not to do this:

If we don't want to do a major version bump we need to do the following:

  • move head-browser-initializer to the addon folder
  • Use the treeForFastboot hook to emit the old fastboot files when Ember version of application is < 2.10
  • Use an AST transform to modify the user's application.hbs to include the invocation of {{head-layout}} component.
    • In an ideal world we'd be able to do this more naively in a broccoli-plugin where we just find the actual template file and add it there, but unsure how/if we could do that.

Details

Currently it appends before the didTransition hook from the router happens, which means it is doing this work in the wrong phase of execution. I did some benchmarking with ember-macro-benchmark and noticed this change when using this PR. The experiment is our PR here.

screen shot 2017-08-03 at 2 23 56 pm

Which shows that we are moving the work to the correct place. We can observe this more clearly in the Chrome timeline.

screen_shot_2017-08-03_at_2_39_14_pm

You can see in the above that ember-cli-head triggers a render before the main rendering pass for our application's first frame.

With this PR it looks more like this:

screen_shot_2017-08-03_at_2_46_15_pm

That's the TL;DR (which is too long)

But this is still very much WIP. After discussing this with @rwjblue we decided that this would necessitate a major version bump unless we did a few things to make it backward compat.

Benefits

I'd like to start a discussion about the possible benefits here. With my benchmarking tools I couldn't see a pronounced difference (it isn't 100% clear yet). Though, I would imagine there is some duplicated effort in starting the rendering process from a cold-start twice.

Any thoughts or ideas would be very much appreciated.

Copy link

@kratiahuja kratiahuja left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Overall I am +1 to this approach. It also makes sense to do a major version bump.

@@ -26,6 +26,7 @@
"ember-cli-app-version": "^1.0.0",
"ember-cli-dependency-checker": "^1.3.0",
"ember-cli-eslint": "^3.0.0",
"ember-cli-fastboot": "^1.0.2",

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Why this is added as a devDependnecy?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Primarily to ensure this approach worked in fastboot. Means that we can run ember s and disable JS then inspect the head element. I can remove if that is a problem

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Definitely makes for easier local testing. Not sure if there are any ramifications to the ember-cli-addon-tests?

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Not an issue but I think you could write the tests in fastboot-tests? If it is more against the dummy app, it's fine too.

@rondale-sc
Copy link
Contributor Author

This should be ready for another review. 🍻

Copy link
Member

@rwjblue rwjblue left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Sorry for the delay here @rondale-sc.

  • Can you add a ember-lts-2-12 scenario to .travis.yml and config/ember-try.js?
  • Should we consider adding a blueprint that automatically puts {{head-layout}} to the application's application.hbs? This would be much easier than trying to do it automatically per-build (in a blueprint we can just use Blueprint.prototype.insertIntoFile)...

@@ -1 +1,3 @@
<meta name="ember-cli-head-start">{{head-content}}<meta name="ember-cli-head-end">
{{#-in-element headElement}}
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

FYI - We have started taking steps to make this public API from the Glimmer VM perspective (see glimmerjs/glimmer-vm#619). It is unclear what Ember version that PR will correspond to, but it is a good step forward for our use case (and shows a future where we can drop the private - prefix).

@rondale-sc
Copy link
Contributor Author

@rwjblue Added 2.12 to the ember-try config. I'm not sure where to begin with the blueprint idea.

@rwjblue
Copy link
Member

rwjblue commented Aug 24, 2017

RE: the blueprint I'm suggesting that we update the blueprint to use Blueprint.prototype.insertIntoFile to insert {{head-layout}}.

@rondale-sc
Copy link
Contributor Author

@rwjblue That's an excellent idea. Will give that a try.

@rondale-sc
Copy link
Contributor Author

I think this is ready to go now.

fs.writeFileSync(fullPath, toWrite, { encoding: 'utf-8' });
} else {
let str = `You must add {{head-layout}} component to your topmost UI.
This is usually your application.hbs, but was not found on your system.
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Maybe use the full path (e.g. app/templates/application.hbs) in the message?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Updated! 🍻

normalizeEntityName: function() { }
normalizeEntityName: function() { },
afterInstall() {
let fullPath = path.join(this.project.root, 'app/templates/applicati.hbs');
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Typo here (should be app/templates/application.hbs)

@rwjblue
Copy link
Member

rwjblue commented Aug 29, 2017

LGTM, thanks for working through this with us!

@kratiahuja - Would you like to do a final review before landing and releasing?

@kratiahuja
Copy link

Sure I'll take a look at it in a while

Copy link

@kratiahuja kratiahuja left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Looks good! Thanks @rondale-sc for the work here. I also think this needs a README update for folks needing to do the major version bump.

@rondale-sc
Copy link
Contributor Author

@kratiahuja Thank you for reviewing. I added a section to the README and blueprint to help people moving from earlier versions. I wasn't sure what the version would be for this so I guessed and used 0.4.x for the README section title, but I'll update that once this is ready to go.

👍

@rondale-sc
Copy link
Contributor Author

Is there anything else blocking this before we cut a release?

@rwjblue rwjblue merged commit 17b1e57 into ember-fastboot:master Sep 19, 2017
@rwjblue
Copy link
Member

rwjblue commented Sep 19, 2017

Thank you for all of your hard work here @rondale-sc!

@Turbo87
Copy link

Turbo87 commented Sep 22, 2017

@rondale-sc @rwjblue am I interpreting correctly that this PR dropped support for Ember 2.4 and 2.8? might be worth it to mention that explicitly in the README and point to the v0.3.x releases for those Ember versions

@rwjblue
Copy link
Member

rwjblue commented Sep 22, 2017

@Turbo87 - Yep, you are correct. Happy to review and land a PR updating the README...

@Turbo87
Copy link

Turbo87 commented Sep 22, 2017

Hmm I just noticed this in the README:

Take into account that version >= 0.3 of this addon require Ember 2.10+ and fastboot >=1.0.rc1 Please use 0.2.X if you don't fulfull both requirements.

Since 0.3.x was still tested against Ember 2.4 and 2.8 is that statement actually valid? I'm a little confused... 🤔

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

4 participants