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...