3 ms·
What I don't like on current state of server side rendering with hydration is that server still sends initial state data, even thought, it is already contained
by finchisko 7y ago
What I don't like on current state of server side rendering with hydration is that server still sends initial state data, even thought, it is already contained within initial html. This means, that site is rendered twice on first load. First time from html and second time after initial state (some json) arrives as state atom is usually null at this time. Why can be initial state just reconstructed from html (data-attributes ...).
- wmf 7y agoI guess you could write "unrendering" code for each component that transforms HTML into its internal state (if that's even possible) and you'd have to keep that code path up to date with any changes to your rendering code. This sounds really error-prone compared to hydration.
- cjblomqvist 7y agoThere are many nuances though. Some data/state may not actually be rendered but used for later. It's also not really accurate to say it's rendered twice, as it's rather hydrated (before hydration this used to be a big problem; sites actually rerendering/flashing when the js loaded/initiated).
- finchisko 7y ago>It's also not really accurate to say it's rendered twice Not sure if we're on same boat here :). By rendered twice I mean: Let's imagine we use React and some store management like redux. 1. Visit some SSR rendered site. Browser receives html (which represents some initial state of an app - rendered by the server) 2. Browser fetches some json representing initial state (hydration). It's the same state that server used for rendering html. 3. State atom was null in step 1. and changed to some initial state in step 2, which basically means full rerender (second) of an app.