Hydration fails with nested props arrays/objects

[eyelidlessness]

Hydration fails with nested props arrays/objects

[ratorx]

The only general solution is base64 (or some other safe serialisation). Otherwise e.g. strings that contain HTML will be rendered by the browser rather than treated as part of the JSON regardless of how the JS parses it.

[eyelidlessness]

The other solutions are viable.

The special token solution is used in multipart payloads (eg every time you submit an HTML form with file upload or open an HTML email, so ~every day for regular internet users), and the multiline string solution for most shells and many shell inspired languages.

Separating the markers from the props is just a hash map reference, the marker referencing a key in the hydration props payload. They all have tradeoffs. Base-64 has the most costly tradeoff but it’s the least impact to implement.

[eyelidlessness]

Another solution that’s probably a much bigger lift would be a huge win if possible: don’t mount with props at all. Effectively memoize on the server.

The big cost (for users) here is second render because you need a comparison algorithm that’s efficient, and JS doesn’t have one. The big cost (for devs) is accounting for that. But if you squint a little bit it’s actually not a big deal. Just mount noop on load and render on first lifecycle check and don’t worry about the diff. Or async trigger the second render on idle/visible. It’s the same expense with no payload at all.

And dang it feels good to be a gangsta check my own intuitions when they’re questioned.

[ratorx]

Sorry I should have been more clear. I agree that the other solutions would work for the JSON parsing case, but my point is that it's worth doing the safe serialisation one because of a different problem (which the other methods can't solve):

The problem is that hydration props like:

{
	"key": "<script>alert()</script>"
}

without safe serialisation will cause the script to be executed by the browser.

EDIT: Memoizing on the server effectively embeds the payload into JS, which also sidesteps this problem, so that's viable too.

[eyelidlessness]

That wouldn’t be a problem if the data is actually JSON treated as such, either:

• escaped in the way it already is
• serialized separately as a hashmap
• serialized with the component for async mount per my new suggestion

[eyelidlessness]

Actually you’re right there is a potential XSS (self own or not), JSON serialization doesn’t account for it. So some change in that regard is definitely warranted as well.

[eyelidlessness]

I think serializing into JS is the common theme here and regardless of the rest of the specifics it’s a clear win.