Changes to Suspense effects semantics

[bvaughn]

Last week I posted about a new "strict effects" mode and how it would impact effects for development builds. React 18 will also include a small change to how layout effects work with Suspense. This thread explains that change and how you can prepare for it.

What's changing?

If a component mounts within a Suspense boundary and is later hidden (because of something else suspending), React will cleanup that component’s layout effects by calling useLayoutEffect cleanup functions or componentWillUnmount. After the suspended boundary resolves, React will recreate the component’s layout effects again by calling useLayoutEffect or componentDidMount.

This change is being made to avoid bugs that may occur from things like reading layout in a hidden tree.

Will this impact a lot of my code?

The scenario described above is not common and can be avoided entirely by using the new useTransition API to ensure that Suspense does not revert to its fallback state after being mounted.

For example, here is a state update that might cause the ProfilePage component to re-suspend afer mounting:

function Example() {
  const [resource, setResource] = useState(initialResource);
  return (
    <>
      <button
        onClick={() => {
          const nextUserId = getNextId(resource.userId);
          setResource(fetchProfileData(nextUserId));
        }}
      >
        Next
      </button>
      <Suspense fallback={<Spinner />}>
        <ProfilePage resource={resource} />
      </Suspense>
    </>
  );
}

Wrap the state update in a "transition" to prevent the ProfilePage from being unmounted while suspending. This lets React know that it should wait for the update to complete:

function Example() {
  const [resource, setResource] = useState(initialResource);
  const [startTransition, isPending] = useTransition(SUSPENSE_CONFIG);
  return (
    <>
      <button
        disabled={isPending}
        onClick={() => {
          startTransition(() => {
            const nextUserId = getNextId(resource.userId);
            setResource(fetchProfileData(nextUserId));
          });
        }}
      >
        Next
      </button>
      <Suspense fallback={<Spinner />}>
        <ProfilePage resource={resource} />
      </Suspense>
    </>
  );
}

As a bonus, React also returns an isPending value which can be used for things like disabling the button while the previous transition is still in progress.

We expect that most effects should "just work" with this change because of strict effects mode. Refer to this post for examples of the types of effects that may require changes.

Related posts

For more information on strict effects, see:

• Adding "strict effects" to <StrictMode>
• How to support strict effects

[alvarlagerlof]

Does isPending switch to false if there is an error?

[rickhanlonii]

I think the situation @alvarlagerlof may be talking about is when there's an error in a child of a parent that uses useTransition while rendering the isPending=true UI. For example, if we throw while rendering a spinner for a filter button while the filter items in the children load.

In that case, yes, isPending will switch to false when rendering the transition update, the user may not see an error boundary in the intermediate state. This is because we render the error bounday for isPending=true, but then swap the new content in from the transition update.

So the flow is:

• Click button to queue transition update
• Set isPending to true and render isPending
• Throw error on isPending (show error boundary, may not be seen)
• Render the transition update with isPending false
• Commit new UI

Here's a codesandbox.

Note that Create React App does show the error overlay for the error, but this is distinct from the boundary.

[bvaughn]

I think the Sandbox above is a little confusing, because of how the thrown error gets cleared out when isPending is reset to false (where as with a "real" use case, presumably the error would be somehow tied to the suspense data and may not reset this way?) In that case, I believe the error boundary would work like usual (stay in an errored state) even after the transition was finished.

[rickhanlonii]

Good call out! In this case, the question seems specific to when isPending is true. It doesn't need to be tied directly to isPending like in the codesandbox, it could be inside a Spinner component which only renders when isPending is true.

[alvarlagerlof]

I think the situation @alvarlagerlof may be talking about is when there's an error in a child of a parent that uses useTransition while rendering the isPending=true UI.

This is exactly what I meant. I think I understand now.

it could be inside a Spinner component which only renders when isPending is true.

This is what I was imagining, yes.

[rickhanlonii]

Here's a more realistic example, with the same behavior.

[gaearon]

Fixed in the latest alpha.
https://codesandbox.io/s/react-18-layouteffect-semantics-forked-m02w5?file=/src/App.js

[tretikoff]

Currently after resuspending useLayoutEffect cleanup functions or componentWillUnmount are being called, while the useEffect cleanup function is not being called.

But the React doc is saying:

React performs the cleanup when the component unmounts

Is this expected behavior? Could we rely on it and expect that effect cleanup will not be called when the component gets hidden inside Suspense?

[Andarist]

Could we rely on it and expect that effect cleanup will not be called when the component gets hidden inside Suspense?

As far as I know - no. Effects are supposed to be symmetric, each "setup" is followed by a "cleanup". In other words, this sequence is not valid/not possible: setup -> setup -> cleanup.