Utilize rehydration serialization from glimmer #580

rondale-sc · 2018-02-23T20:41:22Z

This is part of an arching plan to introduce Glimmer's
rehydration/serializtion modes to Ember proper.

There are 4 PR's that are all interwoven, of which, this is one.

Glimmer.js: Fix failing test rehydration initial content PR glimmerjs/glimmer-vm#783 (comment)
Ember.js: Allow visit to specify Rehydration/Serialization or default ClientBuilder emberjs/ember.js#16227
Fastboot: Rehydration fastboot#185
EmberCLI Fastboot: Utilize rehydration serialization from glimmer #580

In order of need to land they are:

Glimmer.js:
glimmerjs/glimmer-vm#783 (comment)

This resolves a rather intimate API problem. Glimmer-vm expects a very
specific comment node to exist to know whether or not the rehydration
element builder can do it's job properly. If it is not found on the
first node from rootElement it throws.

In fastboot however we are certain that there will already be existant
elements in the way that will happen before rendered content.

This PR just iterates through the nodes until it finds the expected
comment node. And only throws if it never finds one.

Ember.js:
emberjs/ember.js#16227

This PR modifies the visit API to allow a private _renderMode to be
set to either serialize or rehydrate. In SSR environments the
assumption (as it is here in this fastboot PR) is that we'll set the
visit API to serialize mode which ensures glimmer-vm's serialize element
builder is used to build the API.

The serialize element builder ensures that we have the necessary fidelty
to rehydrate correctly and is mandatory input for rehydration.

Fastboot:
ember-fastboot/fastboot#185

This allows enviroment variable to set _renderMode to be used in Visit
API. Fastboot must send content to browser made with the serialization
element builder to ensure rehydration can be sucessful.

EmberCLI Fastboot:
#580

Finally this does the fun part of disabling the current
clear-double-render instance-initializer

We first check to ensure we are in a non-fastboot environment. Then we
ensure that we can find the expected comment node from glimmer-vm's
serialize element builder. This ensures that this change will only
effect peoeple who use ember-cli-fastboot with the serialized output
from the currently experimental fastboot setup

Then we ensure ApplicationInstance#_bootSync specifies the rehydrate
_renderMode.

This is done in _bootSync this way because visit is currently not used
to boot ember applications. And we must instead set bootOptions this
way instead.

We also remove the markings for fastboot-body-start and
fastboot-body-end to ensure clear-double render instance-initializer
is never called.

This is part of an arching plan to introduce Glimmer's rehydration/serializtion modes to Ember proper. There are 4 PR's that are all interwoven, of which, this is one. In order of need to land they are: Glimmer.js: glimmerjs/glimmer-vm#783 (comment) This resolves a rather intimate API problem. Glimmer-vm expects a very specific comment node to exist to know whether or not the rehydration element builder can do it's job properly. If it is not found on the first node from `rootElement` it throws. In fastboot however we are certain that there will already be existant elements in the way that will happen before rendered content. This PR just iterates through the nodes until it finds the expected comment node. And only throws if it never finds one. --- Ember.js: emberjs/ember.js#16227 This PR modifies the `visit` API to allow a private _renderMode to be set to either serialize or rehydrate. In SSR environments the assumption (as it is here in this fastboot PR) is that we'll set the visit API to serialize mode which ensures glimmer-vm's serialize element builder is used to build the API. The serialize element builder ensures that we have the necessary fidelty to rehydrate correctly and is mandatory input for rehydration. --- Fastboot: ember-fastboot#185 This allows enviroment variable to set _renderMode to be used in Visit API. Fastboot must send content to browser made with the serialization element builder to ensure rehydration can be sucessful. --- EmberCLI Fastboot: ember-fastboot/ember-cli-fastboot#580 Finally this does the fun part of disabling the current clear-double-render instance-initializer We first check to ensure we are in a non-fastboot environment. Then we ensure that we can find the expected comment node from glimmer-vm's serialize element builder. This ensures that this change will only effect peoeple who use ember-cli-fastboot with the serialized output from the currently experimental fastboot setup Then we ensure `ApplicationInstance#_bootSync` specifies the rehydrate _renderMode. This is done in `_bootSync` this way because visit is currently not used to boot ember applications. And we must instead set bootOptions this way instead. We also remove the markings for `fastboot-body-start` and `fastboot-body-end` to ensure clear-double render instance-initializer is never called.

This is part of an arching plan to introduce Glimmer's rehydration/serializtion modes to Ember proper. There are 4 PR's that are all interwoven, of which, this is one. - [ ] Glimmer.js: glimmerjs/glimmer-vm#783 (comment) - [ ] Ember.js: emberjs/ember.js#16227 - [ ] Fastboot: ember-fastboot/fastboot#185 - [ ] EmberCLI Fastboot: ember-fastboot#580 In order of need to land they are: Glimmer.js: glimmerjs/glimmer-vm#783 (comment) This resolves a rather intimate API problem. Glimmer-vm expects a very specific comment node to exist to know whether or not the rehydration element builder can do it's job properly. If it is not found on the first node from `rootElement` it throws. In fastboot however we are certain that there will already be existant elements in the way that will happen before rendered content. This PR just iterates through the nodes until it finds the expected comment node. And only throws if it never finds one. --- Ember.js: emberjs/ember.js#16227 This PR modifies the `visit` API to allow a private _renderMode to be set to either serialize or rehydrate. In SSR environments the assumption (as it is here in this fastboot PR) is that we'll set the visit API to serialize mode which ensures glimmer-vm's serialize element builder is used to build the API. The serialize element builder ensures that we have the necessary fidelty to rehydrate correctly and is mandatory input for rehydration. --- Fastboot: ember-fastboot/fastboot#185 This allows enviroment variable to set _renderMode to be used in Visit API. Fastboot must send content to browser made with the serialization element builder to ensure rehydration can be sucessful. --- EmberCLI Fastboot: ember-fastboot#580 Finally this does the fun part of disabling the current clear-double-render instance-initializer We first check to ensure we are in a non-fastboot environment. Then we ensure that we can find the expected comment node from glimmer-vm's serialize element builder. This ensures that this change will only effect peoeple who use ember-cli-fastboot with the serialized output from the currently experimental fastboot setup Then we ensure `ApplicationInstance#_bootSync` specifies the rehydrate _renderMode. This is done in `_bootSync` this way because visit is currently not used to boot ember applications. And we must instead set bootOptions this way instead. We also remove the markings for `fastboot-body-start` and `fastboot-body-end` to ensure clear-double render instance-initializer is never called.

rwjblue · 2018-02-23T22:01:43Z

vendor/experimental-render-mode-rehydrate.js

+    var current = document.getElementById('fastboot-body-start');
+
+    if (current && current.nextSibling.nodeValue === '%+b:0%') {
+      Ember.ApplicationInstance.reopen({


Is this how we plan to do this long term? Do we have a plan to remove this reopen?

rwjblue · 2018-02-23T22:02:17Z

package.json

@@ -29,7 +29,7 @@
    "ember-cli-lodash-subset": "2.0.1",
    "ember-cli-preprocess-registry": "^3.1.0",
    "ember-cli-version-checker": "^2.1.0",
-    "fastboot": "^1.1.3",
+    "fastboot": "github:rondale-sc/fastboot#utilize-rehydration-serialization-from-glimmer",


Just notating that this will need to be bumped to a release version before landing...

rwjblue · 2018-02-23T22:08:35Z

vendor/experimental-render-mode-rehydrate.js

+  if (typeof FastBoot === 'undefined') {
+    var current = document.getElementById('fastboot-body-start');
+
+    if (current && current.nextSibling.nodeValue === '%+b:0%') {


We really really need a way to avoid encoding this, can you make an issue in glimmer-vm to expose a isRehydrationComment function that both Ember and ember-cli-fastboot can use? I'm concerned with the serialize markers changing over time (they have already changed once!?!) and then ember-cli-fastboot will have issues with cross-ember compat...

I totally agree! I'll make the issue.

This is dependent on this glimmer-vm PR to actually work glimmerjs/glimmer-vm#788. Which means we'll need to wait until it is merged/bumped and Ember itself updates to use the release with it in it before we can land this. The idea here is to insulate things that depend on the magic string we use to determine whether or not the DOM node we pass was produced by the serialization element builder. This needs to be exposed on the global to ensure we can use it in the ember-cli-fastboot vendor file so we can determine how to boot the app when it is loaded in the browser. To see where it'd be used in ember-cli-fastboot please see this PR with the in progress work: ember-fastboot/ember-cli-fastboot#580

rondale-sc · 2018-03-06T18:13:11Z

Closed and reopened to trigger another Travis build

rondale-sc · 2018-03-06T19:00:22Z

@rwjblue This is ready once ember-fastboot/fastboot#185 lands

rondale-sc · 2018-03-10T18:12:31Z

@kratiahuja @rwjblue I'm not sure why these tests are failing. They pass locally, and the only difference seems to be capitalization of the Content Type Header in the acceptance tests

kratiahuja

How would apps opt in into the process.env.EXPERIMENTAL_RENDER_MODE_SERIALIZE ?

kratiahuja · 2018-03-10T19:33:47Z

vendor/experimental-render-mode-rehydrate.js

+    var current = document.getElementById('fastboot-body-start');
+
+    if (current && Ember.ViewUtils.isSerializationFirstNode(current.nextSibling)) {
+      Ember.ApplicationInstance.reopen({


Don't we need to turn off this: https://github.com/ember-fastboot/ember-cli-fastboot/blob/master/app/instance-initializers/clear-double-boot.js ?

The clear-double-boot checks to see if fastboot-body-start is present. If we detect true with Ember.ViewUtils.isSerializationFirstNode we eventually delete fastboot-body-start which prevents the clear-double-render.

kratiahuja · 2018-03-10T19:34:23Z

vendor/experimental-render-mode-rehydrate.js

+  if (typeof FastBoot === 'undefined') {
+    var current = document.getElementById('fastboot-body-start');
+
+    if (current && Ember.ViewUtils.isSerializationFirstNode(current.nextSibling)) {


Why not provide a mixin for folks to add in their app.js itself? I am not sure I am sold on the idea of reopening.

So long as Ember.ViewUtils.isSerializationFirstNode is present consumers of fastboot will never have to worry about this line of code unless fastboot actually encodes the DOM the browser version of Ember receives with the glimmer-vm's serialization element builder. And if the the isSerializationFirstNode triggers true then we know the user has opted in.

Is the Ember.ViewUtils.isSerializationFirstNode a public API?

@kratiahuja It is public.

@rondale-sc - Can you tweak this to be safe when Ember.ViewUtils.isSerializationFirstNode is not present (e.g. you aren’t using >= some 3.2ish canary build ATM)

@rwjblue Updated to ensure typeof Ember.ViewUtils.isSerializationFirstNode === 'function'

kratiahuja · 2018-03-10T19:40:49Z

General question: How will apps opt in or opt out of rehydration? If there are issues, I would rather not have apps break and are forced to not use fastboot.

rondale-sc · 2018-03-10T19:43:43Z

@kratiahuja The way to opt-in once this PR is merged would be to ensure the process.env.EXPERIMENTAL_RENDER_MODE_SERIALIZE is set to true. If that happens all the rest of the pipeline for rehydration should just work based off of that.

kratiahuja · 2018-03-10T19:58:21Z

We discussed this also needs doc updates :)

This is part of an arching plan to introduce Glimmer's rehydration/serializtion modes to Ember proper. There are 4 PR's that are all interwoven, of which, this is one. - [ ] Glimmer.js: glimmerjs/glimmer-vm#783 (comment) - [ ] Ember.js: emberjs/ember.js#16227 - [ ] Fastboot: ember-fastboot/fastboot#185 - [ ] EmberCLI Fastboot: ember-fastboot#580 In order of need to land they are: Glimmer.js: glimmerjs/glimmer-vm#783 (comment) This resolves a rather intimate API problem. Glimmer-vm expects a very specific comment node to exist to know whether or not the rehydration element builder can do it's job properly. If it is not found on the first node from `rootElement` it throws. In fastboot however we are certain that there will already be existant elements in the way that will happen before rendered content. This PR just iterates through the nodes until it finds the expected comment node. And only throws if it never finds one. --- Ember.js: emberjs/ember.js#16227 This PR modifies the `visit` API to allow a private _renderMode to be set to either serialize or rehydrate. In SSR environments the assumption (as it is here in this fastboot PR) is that we'll set the visit API to serialize mode which ensures glimmer-vm's serialize element builder is used to build the API. The serialize element builder ensures that we have the necessary fidelty to rehydrate correctly and is mandatory input for rehydration. --- Fastboot: ember-fastboot/fastboot#185 This allows enviroment variable to set _renderMode to be used in Visit API. Fastboot must send content to browser made with the serialization element builder to ensure rehydration can be sucessful. --- EmberCLI Fastboot: ember-fastboot#580 Finally this does the fun part of disabling the current clear-double-render instance-initializer We first check to ensure we are in a non-fastboot environment. Then we ensure that we can find the expected comment node from glimmer-vm's serialize element builder. This ensures that this change will only effect peoeple who use ember-cli-fastboot with the serialized output from the currently experimental fastboot setup Then we ensure `ApplicationInstance#_bootSync` specifies the rehydrate _renderMode. This is done in `_bootSync` this way because visit is currently not used to boot ember applications. And we must instead set bootOptions this way instead. We also remove the markings for `fastboot-body-start` and `fastboot-body-end` to ensure clear-double render instance-initializer is never called.

This is dependent on glimmerjs/glimmer-vm#788 The idea is to use a function exported by ember-glimmer rather than rely on magic glimmer-vm string.

kratiahuja · 2018-03-11T17:47:08Z

README.md

+
+https://github.com/glimmerjs/glimmer-vm/commit/316805b9175e01698120b9566ec51c88d075026a
+
+In order to utilize rehydration in Ember.js applications we need to ensure that


Don't you need to mention from which version it is available?

Definitely! I just added a small blurb about fastboot / ember.js requirements to address this concern.

kratiahuja · 2018-03-11T17:52:01Z

[email protected] is released.

kratiahuja · 2018-03-13T17:15:32Z

README.md

+by the serialization builder.  If it was, it tells the Ember.js Application to
+use the rehydration builder and your application will be using rehydration.
+
+Rehydration is only compatible with fastboot > 1.1.4, and Ember.js > 3.2.


This needs to be 1.1.4-beta.1

kratiahuja

Once the below is updated and tests pass, this is good to land. We need more tests around this to make sure this doesn't regress but we can do it in the next beta release.

kratiahuja · 2018-03-13T17:16:43Z

package.json

@@ -29,7 +29,7 @@
    "ember-cli-lodash-subset": "2.0.1",
    "ember-cli-preprocess-registry": "^3.1.0",
    "ember-cli-version-checker": "^2.1.0",
-    "fastboot": "^1.1.3",
+    "fastboot": "github:rondale-sc/fastboot#utilize-rehydration-serialization-from-glimmer",


Can you change this to 1.1.4-beta.1?

bantic · 2018-03-13T17:55:32Z

This needs an update to the yarn.lock also — I'll push that in a moment

bantic · 2018-03-13T17:58:59Z

Pushed the updated yarn.lock. @kratiahuja This should be good to go now as soon as tests pass

kratiahuja · 2018-03-13T18:08:00Z

thank you @bantic . I'll merge to master once tests pass and cut a release for beta. I will also create a branch for stable if required and keep that seperate.

rondale-sc · 2018-03-13T18:15:09Z

Thanks @bantic! GitHub editing on an iPad can only get me so far 😜.

kratiahuja · 2018-03-13T19:00:57Z

Thank you @rondale-sc and @bantic ! Merging this and releasing.

kratiahuja · 2018-03-13T19:02:53Z

[email protected] is published.

rondale-sc force-pushed the utilize-rehydration-serialization-from-glimmer branch from 91483a1 to 37d1f21 Compare February 23, 2018 20:53

This was referenced Feb 23, 2018

Rehydration ember-fastboot/fastboot#185

Merged

Fix failing test rehydration initial content PR glimmerjs/glimmer-vm#783

Merged

Allow visit to specify Rehydration/Serialization or default ClientBuilder emberjs/ember.js#16227

Merged

rwjblue reviewed Feb 23, 2018

View reviewed changes

rondale-sc mentioned this pull request Feb 27, 2018

Expose isSerializationFirstNode and SERIALIZATION_FIRST_NODE_STRING glimmerjs/glimmer-vm#788

Merged

rondale-sc mentioned this pull request Feb 27, 2018

Expose ability to detect serialization node. emberjs/ember.js#16300

Merged

rondale-sc closed this Mar 6, 2018

rondale-sc reopened this Mar 6, 2018

rondale-sc force-pushed the utilize-rehydration-serialization-from-glimmer branch from 7d36f20 to a791e17 Compare March 7, 2018 16:46

rondale-sc closed this Mar 9, 2018

rondale-sc reopened this Mar 9, 2018

kratiahuja reviewed Mar 10, 2018

View reviewed changes

rondale-sc added 2 commits March 10, 2018 12:05

Utilize Ember.ViewUtils.isSerializationFirstNode to determine action

b3d2589

This is dependent on glimmerjs/glimmer-vm#788 The idea is to use a function exported by ember-glimmer rather than rely on magic glimmer-vm string.

rondale-sc force-pushed the utilize-rehydration-serialization-from-glimmer branch from a791e17 to b3d2589 Compare March 10, 2018 20:05

rondale-sc added 2 commits March 10, 2018 14:28

Add readme explaining how to opt-in to rehydration

725aedb

Ensure isSerializationFirstNode is defined

91c4f97

kratiahuja requested changes Mar 11, 2018

View reviewed changes

Add version limitations to section in README

6bbffd3

kratiahuja reviewed Mar 13, 2018

View reviewed changes

kratiahuja requested changes Mar 13, 2018

View reviewed changes

rondale-sc added 2 commits March 13, 2018 10:45

Update README.md

d896108

Update package.json

0fceedc

Update yarn.lock

dc53d0d

kratiahuja approved these changes Mar 13, 2018

View reviewed changes

kratiahuja merged commit 1eeef40 into ember-fastboot:master Mar 13, 2018

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Utilize rehydration serialization from glimmer #580

Utilize rehydration serialization from glimmer #580

rondale-sc commented Feb 23, 2018 •

edited

Loading

rwjblue Feb 23, 2018

rwjblue Feb 23, 2018

rwjblue Feb 23, 2018

rondale-sc Feb 24, 2018

rondale-sc commented Mar 6, 2018

rondale-sc commented Mar 6, 2018

rondale-sc commented Mar 10, 2018

kratiahuja left a comment •

edited

Loading

kratiahuja Mar 10, 2018

rondale-sc Mar 10, 2018

kratiahuja Mar 10, 2018 •

edited

Loading

rondale-sc Mar 10, 2018

kratiahuja Mar 10, 2018

rondale-sc Mar 10, 2018

rwjblue Mar 10, 2018

rondale-sc Mar 11, 2018

rwjblue Mar 11, 2018

kratiahuja commented Mar 10, 2018

rondale-sc commented Mar 10, 2018

kratiahuja commented Mar 10, 2018

kratiahuja Mar 11, 2018

rondale-sc Mar 11, 2018

kratiahuja commented Mar 11, 2018

kratiahuja Mar 13, 2018

kratiahuja left a comment

kratiahuja Mar 13, 2018

bantic commented Mar 13, 2018

bantic commented Mar 13, 2018

kratiahuja commented Mar 13, 2018 •

edited

Loading

rondale-sc commented Mar 13, 2018

kratiahuja commented Mar 13, 2018

kratiahuja commented Mar 13, 2018


		https://github.com/glimmerjs/glimmer-vm/commit/316805b9175e01698120b9566ec51c88d075026a

		In order to utilize rehydration in Ember.js applications we need to ensure that

Utilize rehydration serialization from glimmer #580

Utilize rehydration serialization from glimmer #580

Conversation

rondale-sc commented Feb 23, 2018 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

rondale-sc commented Mar 6, 2018

rondale-sc commented Mar 6, 2018

rondale-sc commented Mar 10, 2018

kratiahuja left a comment • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

kratiahuja Mar 10, 2018 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

kratiahuja commented Mar 10, 2018

rondale-sc commented Mar 10, 2018

kratiahuja commented Mar 10, 2018

Choose a reason for hiding this comment

Choose a reason for hiding this comment

kratiahuja commented Mar 11, 2018

Choose a reason for hiding this comment

kratiahuja left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

bantic commented Mar 13, 2018

bantic commented Mar 13, 2018

kratiahuja commented Mar 13, 2018 • edited Loading

rondale-sc commented Mar 13, 2018

kratiahuja commented Mar 13, 2018

kratiahuja commented Mar 13, 2018

rondale-sc commented Feb 23, 2018 •

edited

Loading

kratiahuja left a comment •

edited

Loading

kratiahuja Mar 10, 2018 •

edited

Loading

kratiahuja commented Mar 13, 2018 •

edited

Loading