Server-proof components

A component that works on your laptop is not the same as a component that works for everyone. The real test is not whether it renders on the page you are building right now. It is whether it survives when someone drops it into a server-rendered route, a portal, or a feed that paints a thousand copies of it.

The problem

Say you store the viewer’s preferred feed sort, top posts or latest posts, in localStorage. The naive version reads it during render.

function FeedPreferencesProvider({ children }) {
  const sort = localStorage.getItem('feedSort') || 'top'

  return <div data-feed-sort={sort}>{children}</div>
}

This crashes the moment the feed route is server rendered. There is no localStorage on the server, so the render throws before a single post reaches the browser.

The fix

Browser only APIs should be touched only in the browser. Defer the read to useEffect, which never runs on the server.

function FeedPreferencesProvider({ children }) {
  const [sort, setSort] = useState('top')

  useEffect(() => {
    setSort(localStorage.getItem('feedSort') || 'top')
  }, [])

  return <div data-feed-sort={sort}>{children}</div>
}

Now the server renders the safe default and the client upgrades to the saved preference once it mounts. The component stops caring where it runs, which is the whole point.