somewhatabstract.comsomewhat abstract – but mostly…

somewhat abstract but mostly… Menu and widgets Somewhat Abstract About Me Disclaimer Terms of Service Privacy Policy About Our Cookies Short Stories Hell and Hot Chocolate Pie and Pirates GitHub LinkedIn Trello StackOverflow RSS Soundcloud Spotify LastFM Mastodon Twitter Instagram Facebook Page(an ongoing and effective focus for site performance in general) and from utilizing the Vary header along with our cloud edge service to reduce the amount of traffic the server needs to handle. For example, . It is also great at showing more of roach and my work on that server inspired me to write this blog series in the first place. Option 2 is what many sites do. They deploy the render server with the built client code, and as such, it always has the right paths. While we are leveraging this approach a little since our server imports code from the client folder, going all the way to having to do production builds just to test this in development is not helpful. In addition, this approach does not scale very well. Option 3 is a very useful approach. Using a hook or stateful component to delay client-specific code until after the initial render is a versatile solution to many hydration issues. For example, if you want to add identifiers to your elements to satisfy accessibility requirements (which you should want), you can use a mechanism like this to ensure those identifiers are the same during initial render between the server and client. Those pesky feature detection issues mentioned earlier are also easily fixed with this approach. This is known around Khan Academy is using an SSR placeholder; as in rendering placeholder content during the initial render on both client and server, then replacing that with the real content on subsequent re-renders. There can be a lot of complexity here to avoid unnecessary re-rendering, but when done right, it is a useful tool in the server-side rendering toolkit. The SSR Placeholder In order to avoid unnecessary rendering, such as odd cascading renders where one component delays until the 2nd render, then it’s children do the same, to the point where things nested n levels deep are waiting n+1 render cycles to render for the first time, we have to be smart about implementing our delayed rendering component. For one solution, take a look at the WithSSRPlaceholder component I wrote for Khan Academy’s Wonder Blocks component library, based on earlier work in our engineering team. It tracks state and makes sure that nested uses do not delay any longer than the root instance, avoiding cascading render cycles. Because the server only does a single render and does not mount the component, state changes do not get rendered on the server and we just get a single render, but in the client, the state change triggers another render and we get the update we are looking for 3 . It may seem tempting to just use useEffect or useState , but if you want nice reusable components that can nest happily without those aforementioned cascading renders, then some sort of context is going to be needed. That said, useEffect and useState are perfect for our really simple app to get us hydrating, as this note in the React documentation suggests: To exclude a component that needs layout effects from the server-rendered HTML, render it conditionally with showChild && Child / and defer showing it with useEffect(() = { setShowChild(true); }, []) . This way, the UI doesn’t appear broken before hydration. reactjs.org So, to resolve the hydration error we see in our example app, let’s refactor our logo rendering into a component that uses this technique. import React, {useState, useEffect} from ’react’; import logo from ’./logo.svg’; import ’./App.css’; const SpinningLogo = (props) = { const [showLogo, setShowLogo] = useState(false); useEffect(() = { setShowLogo(true); }, [showLogo]); if (showLogo) { return img src={logo} className="App-logo" alt="logo" /; } return null; }; export default SpinningLogo; import React from ’react’; import {Link, Route, Switch} from "react-router-dom"; import Router from "./Router.js"; import SpinningLogo from "./SpinningLogo.js"; import ’./App.css’; function App(props) { const {ssrLocation} = props; return ( Router ssrLocation={ssrLocation} div className="App" header className="App-header" SpinningLogo / div className="App-links" Link className="App-link" to="/"Home/Link Link className="App-link" to="/about"About/Link Link className="App-link" to="/contact"Contact/Link /div /header section className="App-content" Switch Route path="/about" This is the about page! /Route Route path="/contact" This is the contact page! /Route Route path="/" This is the home page! /Route /Switch /section /div /Router ); } export default App; Now we have a component, SpinningLogo , that manages some state and only renders our logo image when that state is set true . On the initial render in both server and client, it is false and so renders nothing, but on the subsequent render in the client, it is true and we get our logo. Or at least we should. Sadly, running this refactored code causes our server to stop working altogether and we get a confusing error. /Users/jeffyates/git/hello-react-world/client/node_modules/react/cjs/react.development.js:1476 throw Error( "Invalid hook call. Hooks can only be called inside of the body of a function component. This could happen for one of the following reasons:\n1. You might have mismatching versions of React and the renderer (such as React DOM)\n2. You might be breaking the Rules of Hooks\n3. You might have more than one copy of React in the same app\nSee https://reactjs.org/link/invalid-hook-call for tips about how to debug and fix this problem." ); ^ Error: Invalid hook call. Hooks can only be called inside of the body of a function component. This could happen for one of the following reasons: 1. You might have mismatching versions of React and the renderer (such as React DOM) 2. You might be breaking the Rules of Hooks 3. You might have more than one copy of React in the same app See https://reactjs.org/link/invalid-hook-call for tips about how to debug and fix this problem. at resolveDispatcher (/Users/jeffyates/git/hello-react-world/client/node_modules/react/cjs/react.development.js:1476:13) at useState (/Users/jeffyates/git/hello-react-world/client/node_modules/react/cjs/react.development.js:1507:20) at SpinningLogo (/Users/jeffyates/git/hello-react-world/client/src/SpinningLogo.js:6:37) at processChild (/Users/jeffyates/git/hello-react-world/server/node_modules/react-dom/cjs/react-dom-server.node.development.js:3353:14) at resolve (/Users/jeffyates/git/hello-react-world/server/node_modules/react-dom/cjs/react-dom-server.node.development.js:3270:5) at ReactDOMServerRenderer.render (/Users/jeffyates/git/hello-react-world/server/node_modules/react-dom/cjs/react-dom-server.node.development.js:3753:22) at ReactDOMServerRenderer.read (/Users/jeffyates/git/hello-react-world/server/node_modules/react-dom/cjs/react-dom-server.node.development.js:3690:29) at renderToString (/Users/jeffyates/git/hello-react-world/server/node_modules/react-dom/cjs/react-dom-server.node.development.js:4298:27) at renderPage (/Users/jeffyates/git/hello-react-world/server/index.js:13:31) at IncomingMessage.anonymous (/Users/jeffyates/git/hello-react-world/server/index.js:68:29) There’s no need to panic. There are three possible reasons this error suggests might be the cause of our issue: You might have mismatching versions of React and the renderer (such as React DOM’s renderer) You might be breaking the Rules of Hooks You might have more than one copy of React in the same app If we reason through our code, we can work out what is really going on. First, we can check the server and client and verify they are both using the same versions of React and React DOM, and yes, they most definitely are. Second, from looking at the documentation and the fact that this is such a simple case, it is unlikely we are breaking the Rules of...