Hydrate server-rendered apps #48
Conversation
Previously, server-rendering a Clearwater app involved generating the virtual DOM nodes and *replacing* what was rendered by the server. This is pretty inefficient, though, because it has to throw away all of the existing server-rendered nodes. This can be prohibitively expensive on slower devices. This commit lets Clearwater handle the existing DOM nodes as if they were artifacts of a previous Clearwater render.
|
Aaaaand I broke the build. The good news is that, when I say "we're stuck using NPM", I mean just to build the More good news is that this PR also removes the |
|
Looks like this is causing issues after the first render if the first node inside the app-container node isn't the same type as your app's root node. Specifically, the app will only client-render once. This is a problem with apps that:
This is due to the fact that the first DOM node in the body in these cases is a |
Previously, server-rendering a Clearwater app involved generating the virtual DOM nodes and replacing what was rendered by the server. This is pretty inefficient, though, because it has to throw away all of the existing server-rendered nodes. Basically, the first Clearwater render was like Turbolinks, which isn't as fast as you might think.
This PR lets Clearwater handle the existing DOM nodes as if they were artifacts of a previous Clearwater render. The best thing about this is that Clearwater doesn't even have to be what rendered it on the server.
In order to accomplish this, I had to add another JS library. This required shaving at least 3 yaks to enable us to use NPM for all that, but it ends up making our JS assets (current and future) easier to manage. Unfortunately, it also means we're stuck using NPM.
Before this, updating the
virtual-domlibrary was a mess: I included my own flavor of it (includes an important performance optimization not yet merged into the original) which was stored on one of my local machines, but not anywhere else. That made it impossible for anyone but me to update that library and even I couldn't do it if I was away from that machine. This PR streamlines that by using NPM andbrowserify, pulling both of the required runtime dependencies from external sources. This means that Clearwater's canonicalvirtual-domlibrary is now at clearwater-rb/virtual-dom.