This is the process of rendering your components and attaching event handlers. It’s like watering the “dry” HTML with the “water” of interactivity and event handlers.
Input delays are typically caused when a user tries to interact with the page while the main thread is busy and unable to respond right away. On a server-side rendered page, the hydration process can take up a lot of space on the main thread. To improve the FID as well as the user experience, our goal is to reduce and split the work on the main thread into smaller tasks so that the user can start interacting with the page sooner and that the browser can handle these interactions as quickly as possible. That’s where hydration strategies come into play.
Generally it gets sent across in 3 forms:
In SSR, data is fetched, and the HTML is generated from the React components on the server. The HTML is then sent out to the client.
Here are the steps which are followed during SSR:
React 18 offers two major features for SSR:
Streaming HTML lets you start emitting HTML as early as you’d like, streaming HTML for additional content together with the script tags that put them in the right places.
These features solve three long-standing problems with SSR in React:
1. You no longer have to wait for all the data to load on the server before sending HTML. Instead, you start sending HTML as soon as you have enough to show a shell of the app, and stream the rest of the HTML as it’s ready.
3. You no longer have to wait for all components to hydrate to start interacting with the page. Instead, you can rely on Selective Hydration to prioritize the components the user is interacting with, and hydrate them early.
Below we have some methods:
With an app architected this way we only need to serialize the inputs or props to the top level components since we know nothing above them is stateful. We know 100% it can never re-render. That outside of the islands is incapable of change. In so we can solve a lot of the double data problem simply by never sending the data we don't use. If it isn't a top-level input there is no way it can be needed in the browser.
But where do we set the boundaries? Doing it at a component level is reasonable as it is something we as humans can make sense of. But the more granular the islands the more effective they are. When anything under an island can re-render you need to send that code to the browser.
One solution is developing a compiler smart enough to determine state at a sub-component level. In so not only are static branches pruned from our tree but even ones nested under stateful components. But such a compiler would need a specialized Domain Specific Language(DSL) so that it could be analyzed in a cross module fashion.
More importantly, islands means server rendering each page on navigation. This multi-page (MPA) approach is the way the web classically works. But it means no client side transitions and loss of client state on navigation.
Effectively, Partial Hydration is an improved version of our Static Routes above. One where you only pay for the features you use.
Written by: Favour Nwachukwu