Remove layout effect warning on the server

[rickhanlonii]

Overview

This PR unfortunately removes the warning emitted when using layout effects on the server:

useLayoutEffect does nothing on the server, because its effect cannot be encoded into the server renderer's output format. This will lead to a mismatch between the initial, non-hydrated UI and the intended UI. To avoid this, useLayoutEffect should only be used in components that render exclusively on the client. See https://reactjs.org/link/uselayouteffect-ssr for common fixes.

Why this warning exists

The new docs explain this really well. Adding a screenshot because as part of this change, we'll be removing these docs.

Why are we changing it

In practice, users are not just ignoring this warning, but creating hooks to bypass this warning by switching the useLayoutEffect hook on the server instead of fixing it. This battle seems to be lost, so let's remove the warning so at least users don't need to use the indirection hook any more. In practice, if it's an issue, you should see the problems like flashing the wrong content on first load in development.

[react-sizebot]

Comparing: 47cf4e5...d2a176d

Critical size changes

Includes critical production bundles, as well as any change greater than 2%:

Name	+/-	Base	Current	+/- gzip	Base gzip	Current gzip
oss-stable/react-dom/cjs/react-dom.production.min.js	=	157.42 kB	157.42 kB	=	50.15 kB	50.15 kB
oss-experimental/react-dom/cjs/react-dom.production.min.js	=	159.01 kB	159.01 kB	=	50.66 kB	50.66 kB
facebook-www/ReactDOM-prod.classic.js	=	541.95 kB	541.95 kB	=	96.53 kB	96.53 kB
facebook-www/ReactDOM-prod.modern.js	=	525.68 kB	525.68 kB	=	94.09 kB	94.09 kB

Significant size changes

Includes any change greater than 0.2%:

Expand to show

Name	+/-	Base	Current	+/- gzip	Base gzip	Current gzip
oss-experimental/react-server/cjs/react-server.development.js	=	146.21 kB	145.68 kB	=	36.50 kB	36.32 kB
oss-stable-semver/react-server/cjs/react-server.development.js	=	145.56 kB	145.03 kB	=	36.30 kB	36.13 kB
oss-stable/react-server/cjs/react-server.development.js	=	145.56 kB	145.03 kB	=	36.30 kB	36.13 kB

Generated by 🚫 dangerJS against d2a176d

[kachkaev]

Could this problem be solved by allowing popular frameworks to suppress or to show warnings via their config? There are not that many of them these days. For example, there could be some new option in next.config.js which allows people to out out of useLayoutEffect warnings (for a few) while keeping them enabled by default (for many).

// next.config.js
export default { 
  reactStrictMode: true, // already exists
  reactWarningsWhatever: {
    useLayoutEffectOnServerWhatever: false // some new option which defaults to warnings being on
  }
}

Alternatively, this can be solved with an ESLint rule, but I’m not sure if it can reliably detect which components are server-side rendered and which are not 🤔

I do find useLayoutEffect warnings handy!

[atomiks]

Thank you! I wouldn't consider this unfortunate, because the workarounds aren't viable in practice, especially for library authors.

@kachkaev I don't think a config option should exist, because then library authors (who don't control their consumers' setups) would still need to use the isomorphic hook hack to guarantee the warning will never appear when they don't want the consumer to care about it (which is ever).

Imagine this ergonomic compound component structure, where the Tooltip context provider uses a layout effect to perform measurements when TooltipContent renders. The fact that this tree is rendered during SSR is clearly fine, because only TooltipTrigger displays initially.

<Tooltip>
  <TooltipTrigger>My trigger</TooltipTrigger>
  <TooltipContent>My content</TooltipContent>
</Tooltip>

The "workarounds" require the parent of this tree know the rendering state of TooltipContent (which is handled by Tooltip already for them, and also would require moving any measurement effects into TooltipContent itself), which should not be necessary. This can and should be naturally SSR rendered without issue, which is why all library authors import useIsomorphicLayoutEffect to make things like this work for their consumers because we don't control their component structure (not just this compound one, but many many other types).

[gaearon]

Could this problem be solved by allowing popular frameworks to suppress or to show warnings via their config?

We generally don't do global configs because they're non-compositional. I.e. a random component on npm is not expected to think about all combinations of different options that could be off or on. Strict Mode is one but it's built-in, not global, and only introduces one "split". It's also default in many setups. Introducing more fragmentation, especially for something so niche, is not worth it.

Imagine this ergonomic compound component structure, where the Tooltip context provider uses a layout effect to perform measurements when TooltipContent renders. The fact that this tree is rendered during SSR is clearly fine, because only TooltipTrigger displays initially.

I don't think I see the reason for a layout effect with this API. Tooltip could have state that defaults to false. Flip that state to true in a regular Effect (meaning the hydration is done), and render TooltipImpl which contains the actual layout effect and does the positioning. I think it could work. But yes, not super ergonomic. I guess it also requires rendering in two passes which is not great.

[atomiks]

@gaearon in practice, has anyone used the conditional component rendering method instead of the isomorphic hook hack? It seems even worse, because the hook technique is easier to use, prevents an extra render, and doesn't cause the button trigger to re-mount due to re-parenting(? not sure on that), which could have unwanted side-effects in some cases.

function Tooltip({children}) {
  const [hydrated, setHydrated] = useState(false);
  useEffect(() => setHydrated(true), []);
  return hydrated 
    ? <ClientTooltip>{children}</ClientTooltip> 
    : <ServerTooltip>{children}</ServerTooltip>;
}

Keep in mind too, that some libs only export hooks which are used by the consumer to build their components, which would force the consumer to know and structure things like this (not practical). e.g. APIs like in Ariakit:

function App() {
  const state = useTooltipState(); // contains the layout effect
  return <>
    <TooltipAnchor state={tooltip} as={Button} className="button secondary">
      Hover or focus on me
    </TooltipAnchor>
    <Tooltip state={tooltip} className="tooltip">
      Tooltip
    </Tooltip>
  </>;
}

I mentioned this in the 2019 issue as well, this has always been something that only needs thorough documentation, not a warning. Making it clear that effects only run on the client, after the first from render on the server, is only something that needs to be understood once, and this seems reasonable to me otherwise:

"In practice, if it's an issue, you should see the problems like flashing the wrong content on first load in development."