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

Utilize rehydration serialization from glimmer #580

Merged
Show file tree
Hide file tree
Changes from 4 commits
Commits
File filter

Filter by extension

Filter by extension


Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
35 changes: 35 additions & 0 deletions README.md
Original file line number Diff line number Diff line change
Expand Up @@ -399,6 +399,41 @@ export default Ember.Route.extend({
```
And they still take advantage of caching in the `shoebox`. No more redundant AJAX for already acquired data. Installation details are available in the addon [README](https://github.com/appchance/ember-cached-shoe#ember-cached-shoe).

### Rehydration

What is Rehydration?

The rehydration feature means that the Glimmer VM can take a DOM tree
created using Server Side Rendering (SSR) and use it as the starting
point for the append pass.

See details here:

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

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

Choose a reason for hiding this comment

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

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

Copy link
Contributor Author

Choose a reason for hiding this comment

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

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

both server side renderers (like fastboot) properly encode the DOM they send to
the browser with the serialization format (introduced in the commit above) AND
that the browser instantiated Ember.js application knows to use the rehydration
builder to consume that DOM.

Rehydration is 100% opt-in, if you do not specify the environment flag your
application will behave as it did before!

We can opt-in to the rehydration filter by setting the following environment
flag:

```
EXPERIMENTAL_RENDER_MODE_SERIALIZE=true
```

This flag is read by Ember CLI Fastboot's dependency; fastboot to alert it to
produce DOM with the glimmer-vm's serialization element builder. This addon
(Ember CLI Fastboot) then uses a utility function from glimmer-vm that allows
it to know whether or not the DOM it received in the browser side was generated
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.

## Build Hooks for FastBoot

### Disabling incompatible dependencies
Expand Down
1 change: 1 addition & 0 deletions index.js
Original file line number Diff line number Diff line change
Expand Up @@ -58,6 +58,7 @@ module.exports = {
app.options.fingerprint.generateAssetMap = true;
}

app.import('vendor/experimental-render-mode-rehydrate.js');
// get the app registry object and app name so that we can build the fastboot
// tree
this._appRegistry = app.registry;
Expand Down
2 changes: 1 addition & 1 deletion package.json
Original file line number Diff line number Diff line change
Expand Up @@ -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",
Copy link
Member

Choose a reason for hiding this comment

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

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

Copy link
Contributor

Choose a reason for hiding this comment

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

Can you change this to 1.1.4-beta.1?

"fastboot-express-middleware": "^1.1.0",
"fastboot-transform": "^0.1.2",
"fs-extra": "^4.0.2",
Expand Down
29 changes: 29 additions & 0 deletions vendor/experimental-render-mode-rehydrate.js
Original file line number Diff line number Diff line change
@@ -0,0 +1,29 @@
(function() {
if (typeof FastBoot === 'undefined') {
var current = document.getElementById('fastboot-body-start');

if (
current &&
typeof Ember.ViewUtils.isSerializationFirstNode === 'function' &&
Ember.ViewUtils.isSerializationFirstNode(current.nextSibling)
) {
Ember.ApplicationInstance.reopen({
Copy link
Member

Choose a reason for hiding this comment

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

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

Copy link
Contributor

Choose a reason for hiding this comment

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

Copy link
Contributor Author

Choose a reason for hiding this comment

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

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.

_bootSync: function(options) {
if (options === undefined) {
options = {
_renderMode: 'rehydrate'
};
}

return this._super(options);
}
});

// Prevent clearRender by removing `fastboot-body-start` which is already
// guarded for
current.parentNode.removeChild(current);
var end = document.getElementById('fastboot-body-end');
end.parentNode.removeChild(end);
}
}
})();