Where you render a React component matters
- Publication date
- May 1st, 2025
In my last post, I laid down some basics on what React elements actually are, how writing JSX makes creating them easier, and that "rendering" a React "component" ultimately just means executing a function to return a React element object of some kind.
Just like any other language that uses lexical scope, a function in JavaScript can only execute if the variables used inside it have definitions that are found within either the function's scope or an ancestor scope.
TL;DR - components rendered in the browser can use browser stuff, and components rendered on a server can use server stuff.
Consider this React component:
function FocusedTagName() {
const tagName = document.activeElement?.tagName;
return tagName ? (
<div>The focused element is a "{tagName}"</div>
) : null;
}
When this component renders, it will show the name of the focused element in the document
, if any. This works just fine if this function is run in a browser, as document
is globally defined. But if this function is run in a server runtime, such as Node.js or Bun, we'll get an error saying that document
is undefined.
Me: Ok fine, just render this component in the browser; problem solved.
You: Yeah, but I want to prove to my friends that I'm a Serious React Developer, so I should use Server-Side Rendering (SSR) because servers are cool and stuff.
Me: Ugh, ok fine, if you must. We'll talk about that next time...