Open ratorx opened 3 years ago
I thought about this some more and refined the idea a bit. What this boils down to is to support components as props to partially hydrated components. Not all components can be passed in as props, only those that don't need to be interactive. These can be marked by a special HOC.
withHydrate
will allow props and children which are marked by the special HOC. For these components, it will:
{"content": base64 encoded html, "__microsite_component": true}
).On the client, the hydration logic will:
preact-markup
) (this is optional, the alternative is just to use dangerouslysetinnerhtml)This lets you write normal components for partial hydration and have component props "magically work" to some extent. Obviously it's a bit complex and it would possibly introduce a new dependency (preact-markup
), but it would remove the restriction that props to hydrated components need to be simple JSON.
This would remove the 3rd caveat from the Automatic Partial Hydration
docs (to some extent).
This is a very awesome idea! I'm thinking this over, but your proposed implementation sounds right to me. I will start kicking the tires on this one 😄
I tried out some of the encoding ideas for a proof-of-concept. Not really in a shareable format yet, but I'll try and setup a branch or something. A few extra notes:
Preact.isValidElement
to decide when to encode to base64 (and add the __microsite_component
tag).react-dom-fragment
or preact-markup
to make this work. I think preact-markup
is the neater option, especially since it allows the VDOM to be updated incrementally.withHydrate
anywhere inside it, there's the potential of weird things happening (possibly, haven't properly tested it). It doesn't find the parent hydrated component (since the rendering happens out-of-order). There needs to be some logic to detect withHydrate
used in component props and error on it. An easy way to detect this might be to wrap component props with a HydrationContext
before rendering it to a string. Then nested withHydrate
can be detected in the same way as it currently is.I created #148 for something tangentially related to the third point. Even if you choose to do it, using withHydrate
inside a component prop should be an error, because there is no chance that the prop is hydrated (since it is statically rendered on the server and passed as plain HTML), so the code will need a special case for that.
Nice! Excited to see what you've been playing with.
One other idea I've been thinking about in regard to optimizing hydration is somehow replacing any non-hydrated components with a noop
component using Preact's shouldComponentUpdate
to opt out of any DOM mutations for static components. Preact's hydrate
function does not try to reconcile the DOM so what was SSR'd won't be wiped out.
The client would render the entire component tree like a typical Preact app, but all static stuff would be removed via treeshaking. That would have the added benefit of all context
working normally and not needing to worry about nested hydration. The withHydrate
HOC would only instruct Microsite not to convert a given component to a noop
. Still need to explore how lazy hydration would work, though!
I like the tree-shaking idea as a different way to do hydration with less caveats. However, I don’t think it solves this particular problem.
In this case, I want to avoid hydrating children of a hydrated component. I’m not entirely sure how that would work with the tree shaking idea. I don’t think they are mutually exclusive, but at some point I think the work to serialise/deserialise children would have to be done (with the alternative being to not support it, which would be a shame).
I guess in that world, the default could be to treat children as rich components and have Preact hydrate them normally and introduce a HOC/wrapper to mark them as fully SSR?
I've made a minimal (hopefully working) PoC here.
It currently doesn't work because I can't figure out how to pass the new dependency (preact-markup
) to microsite-runtime.js
. But this is the implementation other than that (I tested it without preact-markup
, by just using a wrapper div
)
I'm a big fan of partial hydration. But, I think the JS bundles can be made smaller. Right now, the code for all children of partially rendered components has to be sent to the client, even if it's not actually required.
Starting example
In this case
FontAwesomeIcon
is an example component that needs no interactivity. It is just a helper component to generate the SVG icon given a name.If it was written like that, hydrating it requires the entire library (in this case
react-fontawesome
) to be bundled. However, the toggle uses only 2 icons, which could easily be SSR rendered at build time. I don't think this is possible to detect automatically (for the same reason thatwithHydrate
is opt-in), but it should be possible to refactor this to not bundlereact-fontawesome
.Vague Implementation
And it's called by passing in the rendered font awesome icons as a prop:
where
SSR
andSSRElement
would be provided as utilities by this project.Details
The tricky bit is the implementation of
SSR
andSSRElement
. A naive one might be forSSR
to render its child to anSSRElement
(which is a light wrapper around an HTML string) and then forSSRElement
to dangerouslysetinnerhtml to the HTML string on the client.Do you think something like this could work? Would this be an useful feature for this project (considering the focus on minimising runtime javascript)?