TomReactDOM
If you've ever developed a SPA with React, you sure have seen the usage of ReactDOM.render(...), a function call of the imported ReactDOM-module. This is your app's very entry point when being loaded on the client, which renders a React-component to the container-view, defined in your HTML. This single React-component then mounts every subsequent view into your DOM, enabling you to use the application written.
But did you know that ReactDOM has another function called hydrate, which does about the same thing but totally different?
Hydrate vs Render
You can build your React-app basically in two variants:
- Your app is architectured as a SPA, where everything gets loaded & executed on client-side
- Your app gets pre-build to a certain extent and made available via SSR (server side rendering), that is as static files that get loaded
As mentioned above, when building a SPA, all you (basically) need to use is ReactDOM at the entry point of your app and then subsequently load all components.
But if you use a static-site-generator such as Next.js or Gatsby, your web application is being built before deployment. Specifically, your site’s pages get generated as far as possible with markup based on the React-components defined in code.
If you’d attempt to render those pre-created components with ReactDOM, an error would arise. Because the actual module to render is ReactDOMServer in this case. Contrary to ReactDOM, ReactDOMServer doesn’t work on the client, but rather in a node environment, which is either a server or serverless function.
After ReactDOMServer rendered your page, all there is left is to put functionality back to it. And this very task is done by ReactDOM.hydrate on the client-side. The hydrate-call expects the container-element in your HTML to be already rendered by ReactDOMServer and only takes care of attaching event-listeners to it.
And that’s about it for a brief introduction to the difference between ReactDOM’s render- and hydrate-calls. Thanks for reading!
- Tom