useLayoutEffect and server rendering

uselayouteffect-ssr.md

If you use server rendering, keep in mind that neither useLayoutEffect nor useEffect can run until the JavaScript is downloaded.

You might see a warning if you try to useLayoutEffect on the server. Here's two common ways to fix it.

Option 1: Convert to useEffect

If this effect isn't important for first render (i.e. if the UI still looks valid before it runs), then useEffect instead.

function MyComponent() {
  useEffect(() => {
    // ...
  });
}

Like useLayoutEffect, it won't run on the server, but it also won't warn.

Option 2: Lazily show component with useLayoutEffect

If UI looks broken with useEffect but gets fixed by useLayoutEffect, it means that this component doesn't look right until the effect runs. However, that means the server-rendered HTML version of it won't look right until JavaScript loads anyway. So server-rendering it brings no benefit and shows a confusing UI.

To fix this, you can delay showing that component until after the client side JS loads and hydrates the component. To exclude a Child that needs layout effects from the server-rendered HTML, you can render it conditionally:

function Parent() {
  const [showChild, setShowChild] = useState(false);
  
  // Wait until after client-side hydration to show
  useEffect(() => {
    setShowChild(true);
  }, []);
  
  if (!showChild) {
    // You can show some kind of placeholder UI here
    return null;
  }

  return <Child {...props} />;
}

function Child(props) {
  useLayoutEffect(() => {
    // This is where your layout effect logic can be
  });
}

For example, this is handy for jQuery plugins which can be initialized later.

---

If you have some use case that isn't covered, please report a complete minimal code example here and we'll try to help.

@gmattie I ended up disabling the error message by using the code from the last post here: reduxjs/react-redux#1373. I used it in my main app.

Option 1. Fixed my problem. I wnt deep into the 'node-modules' and found that affected component and replaced 'useLayoutEffect' to 'useEffect'. - NO MORE ERRORs in console :) Hope i wont find any buggs caused from this fix. :)

Editing the code ourselves requires the patch every time we update React. Another option, as @bradstevanus1 mentioned, is to suppress that specific error message from being logged.

/*
 * @description Suppresses specific messages from being logged in the Console.
 * 
 * @param {string} message - The target message to suppress, either full text, partial text or a regular expression pattern and case-insensitive.
 * @param {string} method - The Console method of the message to suppress, including "error", "info", "log" and "warn". 
 * @public
 * @function
 * 
 * @example
 * 
 *      suppressConsoleMessage("overeager alarm system", "error");
 * 
 *      console.error("An alarm system for a nuclear power plant")  // <-- Logged
 *      console.error("An overeager alarm system for React")        // <-- Not Logged
 *      console.log("An overeager alarm system for React")          // <-- Logged
 * 
 */
const suppressConsoleMessage = (message, method) => {
    const nativeConsoleMethod = console[method];
    console[method] = (nativeMessage) => {
        if (!RegExp(message, "gi").test(nativeMessage)) {
            nativeConsoleMethod(nativeMessage);
        }
    };
};

//~

suppressConsoleMessage("useLayoutEffect does nothing on the server", "error");

I have the same use case @maranomynet
Inital render looks good from server
useLayoutEffect only runs after user action
but then I need layout effect with useEffect I get a ugly flicker

would be nice if I could just silence this… for now I use the useIsoMorphicLayoutEffect hack from above :-(

@sayjeyhi Somehow it seems more correct to me to write:

import { useLayoutEffect } from 'react';

export const useBrowserLayoutEffect = typeof window !== 'undefined' ? useLayoutEffect : () => {};

if you wish to silence the warnings.

Your hook name is misleading, I wouldn't call that isomorphic.

(Also I agree with the first comment)

useLayoutEffect(() => {
    setTimout(() => {
     // logic
    },0)
  });

Everyone is discussing this issue in context of testing. I am seeing this issue due to integrations with non-react library (e.g. leaflet). I'd like to use IconButton and Avatar from material UI as marker on the map. The only solution from leaflet perspective to use DivIcon but it requires to render React Elements to string

const html = new L.DivIcon({
    className: 'my-div-ico',
    html: ReactDOMServer.renderToString(
       <IconButton>
          <Avatar>My</Avatar>
       </IconButton>
    ),
    ...
  })

Are there any suggestions about eliminating the warning in this case? None of proposals discussed in this thread do not work.

Why only warn when useLayoutEffect is used, not when useEffect is used? They both will not run in server side.

Just put this in pages/_app.js or some other top-level place:

// suppress useLayoutEffect warnings when running outside a browser
if (!process.browser) React.useLayoutEffect = React.useEffect;

useLayoutEffect and useEffect have the same argument signature, and neither runs if we're not in a browser.
So if we're not in a browser it's safe to globally replace the one that triggers warnings with the one that doesn't.

(If you don't want to rely on the process global, if (typeof window === 'undefined') works too.)

---

Edit: the above still works, but replacing with () => {} is probably clearer.

Ant Design of React is the cause of this warning in my case. I got the warning when I used import { Menu } from 'antd' and the warning was gone when I commented out the component

@ValeryApps I'm currently facing the same issue (Ant Design + Next.js). Were you able to get around it?

I suppose the initial idea is little bit not valid. Warning said that you should not use useLayoutEffect in components what can be rendered on SSR.
Consider situation when we have some component and this component used on two pages.
I open first page via SSR and hydration (useLayoutEffect does nothing on SSR, and make something after hydration),
and I navigate to page 2 on client side (without SSR) and get page 2 layout where our components used, it does something with useLayoutEffect, all is okay.
BUT: My console spammed with tons of warnings. Suppose I read it and replace all useLayoutEffect with useEffect, and what I get?
It will be the same in case of opening page via SSR (no-op on SSR, action of client), but when navigate to page 2, I notice glitch for some time because of using useLayout instead of useLayoutEffect.

Why react forces me to make application worse than it can be?

---

Long story short: component with useLayoutEffect maybe used not only while SSR, but after client's routing, so the use of the useLayoutEffect should be valid.

In my case checking typeof window did not help. Instead I have mixed @dhovart and @dr-skot answers which leads me to silence warning.

import { useLayoutEffect } from 'react'

export const useBrowserLayoutEffect = process.browser ? useLayoutEffect : () => {}

In my case checking typeof window did not help. Instead I have mixed @dhovart and @dr-skot answers which leads me to silence warning.

import { useLayoutEffect } from 'react'

export const useBrowserLayoutEffect = process.browser ? useLayoutEffect : () => {}

As I know, process.browser works only in Next.js.

I'm using Next.js and simply wrapping useLayoutEffect with a check for window at time of use silenced the warning:

if (typeof window !== "undefined") {
    useLayoutEffect(() => {
        // ...
    });
}

You're not normally supposed to wrap hook calls in conditionals, but because this check always passes on the client and always fails on environments without a DOM I believe it should be fine.

It's just amazing that this kludge is still the closest thing to an "official solution" to the noise-pollution problem.

It's just amazing that this kludge is still the closest thing to an "official solution" to the noise-pollution problem.

I think it's shame... I like React but this decision is beyond common sense.

@ValeryApps @asofiasbo I'm also having the same issue. did you manage to fix it?

I haven't. I gave up on using Ant Design alongside NextJS @mrkan-alelgn

@mrkan-alelgn @ValeryApps
I found the source of this issue in Ant Design issues. I guess we have to wait a bit :)

ant-design/ant-design#30396

Please add an option to suppress this warning.

A more robust version written in typescript

export function UseLayoutEffectParent(props: {
  children: ReactNode
  placeholder?: ReactNode
}) {
  const [showChild, setShowChild] = useState(false)

  // Wait until after client-side hydration to show
  useEffect(() => {
    setShowChild(true)
  }, [])

  if (!showChild) {
    // You can show some kind of placeholder UI here
    return props.placeholder ? <>{props.placeholder}</> : null
  }

  return <>{props.children}</>
}

The problem with some of the solutions here is they require changing your actual code. You have to replace all your useLayoutEffect calls with a custom useBrowserLayoutEffect—or worse, wrap them all in if statements! which is specifically forbidden. You’re kludging perfectly correct code throughout your codebase, for the sole purpose of suppressing a bogus console warning.

And if the offending code is in an imported module, you can't kludge it.

This solution is one line at the top level of your project and you’re done. Note that it changes nothing that’s actually executed. It replaces a function that never runs with a function that does nothing.

// suppress useLayoutEffect (and its warnings) when not running in a browser
if (typeof window === "undefined") React.useLayoutEffect = () => {};

On the server side, useLayoutEffect is never executed but generates a warning. To suppress the warning, replace the never-executed function with noop. On the client side, this replacement doesn't happen, and all your plain old useLayoutEffects run normally, unkludged and unconditional the way God intended.

the way God intended

I didn't come from no monkey(patch)! ;)

I actually think creating an explicit new hook to paper over the lack of error suppression is a better approach than hiding it behind a monkeypatch -- your code works great until you port it to an environment that doesn't patch React...

@cha0s maybe you're right. I'm not aware of an environment where React isn't patchable. I do see your point about making things explicit. But in this case monkeypatching away a method that does literally nothing but pollute the console with unhelpful warnings seems less offensive to me than refactoring the whole codebase to accomplish the same thing. Especially if some of the warnings are coming from imported modules I can't refactor.

And if a future React makes the workaround unnecessary, there's only one line of code to delete.

Why do we need a warning about useLayoutEffect() when we haven't warning about useEffect()? Does anyone expect that useLayoutEffect() will do something on the server?

@tenorok The reason is that useLayoutEffect runs before the DOM is first rendered, whereas useEffect runs after.

With useEffect, the first render on the client is going to be consistent with the server-side render. Because the server doesn't run useEffect, and the client doesn't run it until after the first render.

But useLayoutEffect runs before the client's first render, and the server doesn't run it at all. So there might be a mismatch between the server's render and the client's first render. That's what the warning is telling us.

(Edit: of course, to be technically precise, it's not the functions useEffect and useLayoutEffect, it's the callbacks passed to them, that run at different points in the component lifecycle).

That's the reasoning, but this distinction is really splitting hairs. If useEffect changes the view (without waiting for some sort of promise to resolve) the update probably happens before the user can see the first render. And if useLayoutEffect waits for a promise, the server's render will display in the meantime.

So yeah, warning about one and not the other is highly questionable.

Bad change. No logic. Disagree.

You’re kludging perfectly correct code throughout your codebase, for the sole purpose of suppressing a bogus console warning.

+1

Arrived here cause my console is being polluted with this too. For non SSR WebComponents, all of the recommendation is to use useLayoutEffect to dynamically import the component, but it means I have a ton of these warnings. Need to figure out a way to suppress that works for me.

After learning a lot more about hooks and the lifecycle of SSR with those hooks, I think it is important to mention that useEffect and useLayoutEffect will always run after initial load from the server (I did not get this for some reason the first few times I was on this thread!). This means that whatever you choose to SSR render, will simply render as whatever you put in your return (…) first. Then, your useLayoutEffect will run and then your useEffect. But these happen after your component is already being shown to the user! The lifecycle of useLayoutEffect running before anything has rendered has changed in SSR.

My main use of using useLayoutEffect was the affect height of elements based on window size before they were rendered by SSR, but that is not possible—they have to first render by SSR, which does not have access to the window! If you want something to change visually based on some browser/window state and variables before it is rendered, you cannot use useLayoutEffect or useEffect! The component will first render from server and then run these hooks, leading to size flickering, etc.

For me, it boils down to three options:

1. Change useLayoutEffect to useEffect: This is important because useEffect you can add css transitions to make the re-sizing less jarring and almost unnoticeable. With useLayoutEffect, these transitions often run less smoothly due to the way the hook works. Source: https://blog.thoughtspile.tech/2021/11/15/unintentional-layout-effect/
2. Simply dynamically import the component as a client component only, making useLayoutEffect actually run before first render of the component! (However, the client component renders after server rendered components, making it flicker in if you do not animate it in :( )
3. Lazily show component with useLayoutEffect: This is nearly the same as the approach as I just mentioned in the previous option and the result is nearly the same. Also, it will flicker in unless you animate it in. The main difference with this approach is that the code for the component is not dynamically imported, so it will be bundled (but not show!) with the first render. This approach also seems easier to add animations to.

With SSR, both useLayoutEffect and useEffect run after your first render from the server, so I don’t really see any reason for someone needing to use useLayoutEffect.

For some reason, I just did not grasp this when I first was dealing with this, and came up with many convoluted workarounds. Hopefully this word dump will help someone.