search

reflex-frp / reflex-examples

See Reflex FRP in action with tinker-friendly code samples you can run yourself.
https://reflex-frp.org
BSD 3-Clause "New" or "Revised" License
81 stars 34 forks source link

Bumps reflex-dom to 0.5 #32

Closed benkolera closed 2 years ago

benkolera commented 5 years ago

This updates the examples for the new prerender structure. I cleaned up some warnings about redundant constraints along the way, but I can remove them if you like!

The biggest annoyance is that any widget that cares about which DomBuilderSpace they are working in can only take concrete Elements if they are taking in an element since things didn't seem to line up well with the new Client type family. This has pushed the prerenders further up the widget tree and having bigger prerender blocks.

Hopefully can someone can tell me the trick and tell me where I'm being silly with those and I'll fix them, because it seems like it should be the case that this kind of abstraction should be able to work in spite of the new types (seemingly) prohibiting it.

benkolera commented 5 years ago

Prior to 566d0b7 there was a bug in this where we got a warning: 

reflex-dom warning: hydration failed: the DOM was not as expected at switchover time. This may be due to invalid HTML which the browser has altered upon parsing, some external JS altering the DOM, or the page being served from an outdated cache.

and it broke all of the styling on the page. Was that the 'right' solution there or is there a better way?

tomsmalley commented 5 years ago

Hi, thanks for taking the initiative to do this!

The biggest annoyance is that any widget that cares about which DomBuilderSpace they are working in can only take concrete Elements if they are taking in an element since things didn't seem to line up well with the new Client type family. This has pushed the prerenders further up the widget tree and having bigger prerender blocks.

Indeed, this is because during the first hydration stage we don't actually have any ghcjs-dom Element/TextNode to return from element/textNode and friends, as a consequence of Adjustable and the fact that the statically rendered page represents what should exist at postBuild (switchover) time. Theoretically we should be able to have something like the old behaviour because by the time prerender's client widget is run we know exactly which node we are referencing. Internally this is dealt with by doing some juggling with IORefs so everything lines up at switchover, but I couldn't find a good way to expose this safely. Outside of a prerender block, the DomSpace is HydrationDomSpace rather than GhcjsDomSpace, with the important difference being the types of the various nodes becoming ().

The hydration failed warning is a manifestation of a bug which should be fixed in https://github.com/obsidiansystems/obelisk/pull/402

Ericson2314 commented 2 years ago

Belated as hell, but I built it on mac and linux manually,