Hydration

[aquapi]

Support hydration for SSR

[johnloy]

@justin-schroeder @andrew-boyd Fantastic work, and thanks for advocating for simplicity and the platform ™️ !

I'm interested in the challenge of developing Arrow integration with Astro, ala https://docs.astro.build/en/guides/integrations-guide/lit/. SSR/hydration support are part and parcel of that. Is there perhaps an opportunity for me to try my hand at this, or is this something you already have in the works?

[justin-schroeder]

@johnloy thanks! Very exciting and thanks for offering to pitch in! We can use all the help we can get and currently we are not working on any specific SSR/Hydration — although @danielroe had mentioned being interested in tackling this challenge as well.

Behind the scenes, ArrowJS is mid-stream on a big refactor (with essentially the same API) to significantly boost performance and code readability (its a bit of a jumble right now, more of a proof of concept experiment) — but one of the major things that we are trying to at least consider in this refactor (to be fair, more like a rewrite) is how we could do SSR and hydration in a highly efficient manor. Specifically, since we don’t use a Virtual Dom, its completely possible to ship only the rendered DOM and the expressions that bind to those elements, eliminating the double-html problem.

From a pure SSR perspective Arrow can technically render server side using JSDom "out of the box" — of course, thats not going to be particularly performant. It seems to be something similar could be done by mocking the very small surface area of web API calls Arrow uses to just perform some basic string manipulation and concatenation — or maybe there is a better way 🤷‍♂️

It’s not a problem I've spent much time tackling myself yet, so I would need to approach it with a big slice of humility.

So I guess — yes — please help with SSR and hydration, but I would hate for you to spend much time getting it to work using the current internals. Perhaps we resurrect this thread in a few weeks when we have that stable refactor.

[johnloy]

Wonderful! Speaking of humility, I don't claim to have any big ideas or applicable experience 😬. I'm just very excited by the challenge, and the opportunity to help. That said, I did once start a since-abandoned effort to create a one-size-fits-all SSR/SSG renderer for custom elements using JSDOM (you're right, it's probably not the most performant way). Maybe there's something in there that's useful?

https://github.com/johnloy/static-shadow-dom (the README is a mess)

In any case, thanks for the quick response, and the heads up about the rewrite. For the time being, I'll take a closer look at the current source, to get some ideas flowing. I'm guessing the arrow-refactor-x branches are where the rewrite is happening?

[markmals]

@justin-schroeder

one of the major things that we are trying to at least consider in this refactor (to be fair, more like a rewrite) is how we could do SSR and hydration in a highly efficient manor. Specifically, since we don’t use a Virtual Dom, its completely possible to ship only the rendered DOM and the expressions that bind to those elements, eliminating the double-html problem.

This sounds fairly similar to an idea @ryansolid has been pontificating on recently for Solid: a sort of "on-demand, partial tree" hydration. You can essentially completely eliminate shipping templates to the client for anything besides structural changes by lazily recreating the reactive graph when global event listeners are triggered. These ideas might be worth considering for Arrow since it seems to handle reactivity similarly to Solid: https://hackmd.io/@0u1u3zEAQAO0iYWVAStEvw/Hyu_IZQq2

[justin-schroeder]

Thank’s for the link @markmals!