Commit
This commit does not belong to any branch on this repository, and may belong to a fork outside of the repository.
This commit introduces a "rehydration" mode to the Glimmer VM.
-- 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.
Rehydration is optimized for server-rendered DOMs that will not need
many changes in the client, but it is also capable of making targeted
repairs to the DOM:
- if a single text node's value changes between the server and the
client, the text node itself is repaired.
- if the contents of a `{{{}}}` (or SafeString) change, only the
bounds of that fragment of HTML are blown away and recreated.
- if a mismatch is found, only the remainder of the current element
is cleared.
What this means in practice is that rehydration repairs problems
in a relatively targeted way, and doesn't blows away more content
than the contents of the current element when a mismatch occurs.
Near-term work will narrow the scope of repairs further, so that
mismatches inside of blocks only clear out the remainder of the
content of the block.
-- What Changes Were Needed?
Previously, code in the append pass was permitted to make DOM
changes at any point, so long as they made the changes through
the stateless "DOM Helper" abstraction, which ensured that
code didn't inadvertantly rely upon environment-specific
behaviors. This includes both browser quirks (including the
most recent version of Safari), and restricting Glimmer to
the subset of DOM used in `SimpleDOM`, the library that is
responsible for emulating the DOM in our current Server
Side Rendering implementation.
Rehydration works by replacing attempts to create DOM nodes
with a check for whether the node that Glimmer is trying to
create is already present. It maintains a "cursor" against
the unhydrated DOM, and when Glimmer attempts to create an
element, it first checks to see whether the candidate node
matches the node that Glimmer is trying to create.
For example, if Glimmer wants to create a text node,
the rehydrator checks to see if the node under the cursor
is a text node. If it is a text node, it updates its
contents if necessary. If not, it begins a coarser-grained
repair (which, as described above, is never worse than
clearing out the rest of the DOM for the current element).
This requires that the core DOM operations not only go
through a stateless abstraction (DOM Helper), but also
have a choke-point through a stateful builder that can
maintain the candidate cursor and initiate repairs.
Most of this commit restructures code so that DOM operations during
the append pass go throug the central ElementBuilder in all cases.
Part of this process involved restructuring the code that manages
dynamic content and dynamic attributes to simplify them and make
them a better fit for ensuring that all DOM operations in the
append pass go through the ElementBuilder.
-- Serialize Mode
This commit also introduces a dedicated "serialize" mode that
server-side renderers should use to generate the DOM.
The serialize mode is reponsible for inserting additional markers
into the DOM to serialize boundaries that otherwise serialize
incorrectly.
For example, it inserts a comment node between two adjacent
text nodes so that they remain separated when rehydrating.
The serialize mode does not prescribe a DOM implementation;
any DOM that is compatible with the well-defined SimpleDOM
subset will work (including a real browser's DOM, JSDOM,
or SimpleDOM); it just ensures that the created DOM will
round-trip through a string of HTML.
Importantly, the rehydrator mode assumes that the server-
provided DOM was created in serialize mode.
-- Future Work: Attributes and Properties
Today, when you write something like `<div title={{value}}>`,
Glimmer attempts to use DOM properties if possible. This
works, more or less, because the DOM automatically reflects
properties to attributes in most cases.
This means that if you write `<img src={{url}} />` in a template,
we will set the `src` property, which the DOM automatically
reflects onto the `src` attribute.
Using properties where possible as opposed to attributes in
all cases addresses a number of use cases. For example,
- `<select value={{someValue}}>` will select the correct
`<option>` automatically
- `<div onclick={{action foo}}>` "just works" to set
event handlers.
- `<textarea value={{someValue}}>` updates the inside of
the textarea instead of requiring you to deal with
the text node contents of the textarea.
We intend to move to all-attributes-all-the-time in the future, but
we need to address these use-cases. There are various approaches
under consideration (including a few special-cases, element
modifiers, and an alternate sigil), but they are out of scope
for this PR.
In order to address this gap for now, this PR works around the slight
semantic inconsistency. When the rehydrator pushes an element, it
snapshots the list of all attributes that are already present on
the element as a list of candidates for attribute removal. When
Glimmer attempts to set an attribute **or property** on the element,
the rehydrator removes it from the list of candidates for attribute
removal.
When an element's attributes are "flushed" (a step in the Glimmer
VM), the rehydrator removes any attributes that it didn't see during
the append step.
This should work in the vast majority of cases because:
First, it doesn't stop properties from being set, so any case where
properties were set before continue to be set now.
Second, if an attribute was present and the same-named property was
set in the client, the attribute will remain in the DOM. This
can only go wrong if the application was relying on a property
being set that **didn't** set the same-named attribute. This
is very rare; one example might be if an app was relying on using
`form.reset()` to reset a field back to `''`, relying on the
fact that `<input value={{someValue}}>` doesn't **actually**
set the value attribute.
This is very unlikely because empirically very few people use
`.reset()` in Ember or Glimmer, which is **why using a property
instead of an attribute here worked in the first place**.
In short, if someone is relying on the fact that an element's
attribute actually sets a property also **relies on the fact that
it doesn't set an attribute,** the current workaround will repair
inconsistently. This should be very rare and something we can
address next.- Loading branch information
1 parent
933acfb
commit 316805b