search

varabyte / kobweb

A modern framework for full stack web apps in Kotlin, built upon Compose HTML
https://kobweb.varabyte.com
Apache License 2.0
1.53k stars 68 forks source link

Figure out hydration #113

Open bitspittle opened 2 years ago

bitspittle commented 2 years ago

https://www.google.com/search?q=web+hydration

Right now, when we receive an exported site snapshot from the server, Compose just kills the root node anyway and rebuilds it up.

Eventually, we should find a way to support real hydration, which means we get one frame where we render everything as is quickly but then afterwards we update, in place, the DOM tree.

Maybe we'll need to reimplement our own renderComposable(rootElementId = "root") function, or make some changes and upstream them to JB?

rocketraman commented 2 years ago

Relevant comment from Jake Wharton (Reddit)

bitspittle commented 2 years ago

Relevant excerpt.

Compose retains references to the nodes in your tree (in this case, the DOM elements in the DOM tree) and the local state of your compositions. Both of these need to be serialized and then restored client-side in order to resume from where you left off. Without this, you will have to re-initialize your entire composable tree and emit the entire initial DOM. It's probably fine to do this (and easier), but it's not strictly isomorphic like other JS libraries would be.

The latter part ("Without this, you will have to re-initialize... ") is what Kobweb is currently doing. It's honestly not that bad of an experience as far as I can tell.

The serialization part will be more "fun", because (I assume) it means you need to run a browser on the server and then send that data down somehow.

Cookies are also interesting. Right now, for example, I keep the active color mode in local storage, which means even if I hydrate stuff on the server, if the cookies don't match, I'll still send the wrong colors down.