Hi all:
I’m curious what people’s experience with rehydration + fastboot have been? Have people tested these features out? Is there anything we as the community can do to help?
The only reason I ask is that ember-cli-fastboot is still in beta and for the apps I work on, this is probably the most important feature to make our apps fast as possible (TTI + all other related metrics would improve significantly). Our fastboot setup is a bit complicated, so still working through that before testing out rehydration.
Perhaps the answer is, “it just works”, but I thought I would ask the question in case there was something I/the community could do to help to bring ember-cli-fastboot to a stable release.
ember-fastboot:master ← rondale-sc:utilize-rehydration-serialization-from-glimmer
opened 08:40PM - 23 Feb 18 UTC
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.
- [x] Glimmer.js: glimmerjs/glimmer-vm#783 (comment)
- [x] Ember.js: emberjs/ember.js#16227
- [x] Fastboot: ember-fastboot/fastboot#185
- [ ] EmberCLI Fastboot: ember-fastboot/ember-cli-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/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.
1 Like