Enhancement: Support SSR-able components as props for hydrated components about microsite HOT 7 OPEN

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:

• Render them to an HTML string
• Encode it with something like base64 (otherwise the hydration marker breaks)
• Add a special JSON object to the hydration marker (something like {"content": base64 encoded html, "__microsite_component": true}).

On the client, the hydration logic will:

• Identify special JSON object
• Decode it to HTML
• Parse them into a VDOM/simple component (with something like preact-markup) (this is optional, the alternative is just to use dangerouslysetinnerhtml)
• Pass them as arguments to the hydrated component

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).

from microsite.

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 😄

from microsite.

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:

• The special encoding/decoding is actually really easy because of JSON reviver/replacer. For the encoding, I ended up not using a special HOC but rather just using the components directly and using Preact.isValidElement to decide when to encode to base64 (and add the __microsite_component tag).
• This needs an extra dependency in microsite runtime. AFAIK it's not possible to use dangerouslysetinnerhtml on a fragment (which means that the parsed HTML will always end up with a wrapper element). So the runtime will either need a dependency like 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.
• If the component being encoded contains a 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.

from microsite.

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.

from microsite.

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!

from microsite.

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?

from microsite.

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)

from microsite.