What is tearing?

[rickhanlonii]

Overview

Tearing is a term traditionally used in graphics programming to refer to a visual inconsistency.

For example, in a video, screen tearing is when you see multiple frames in a single screen, which makes the video look “glitchy”. In a user interface, by “tearing” we mean that a UI has shown multiple values for the same state. For example, you may show different prices for the same item in a list, or you submit a form for the wrong price, or even crash when accessing outdated store values.

Since JavaScript is single threaded, this issue generally has not come up in web development. But in React 18, concurrent rendering makes this issue possible because React yields during rendering. This means that when using a concurrent feature like startTransition or Suspense, React can pause to let other work happen. Between these pauses, updates can sneak in that change the data being used to render, which can cause the UI to show two different values for the same data.

This problem isn’t specific to React, it’s a necessary consequence of concurrency. If you want to be able to interrupt rendering to respond to user input for more responsive experiences, you need to be resilient to the data you’re rendering changing and causing the user interface to tear.

This problem was explained in a talk by @flarnie here, but we'll provide a brief overview of the problem here by explaining what happens during synchronous rendering, and concurrent rendering.

Synchronous rendering

Take a look at the figure below.

In the first panel, we begin rendering the React tree. We get to a component that needs to access some external store and get a color value. The external store says that the color is blue, so that component renders blue.

In the second panel, since we’re not concurrently rendering, React continues rendering all of the components without stopping. Since we didn’t stop (or “yield”), then the external store could not have changed. So all of the components get the same value in the external store.

In the third panel, we see that all of the components are rendered as blue, and they all look the same. The UI is always displayed in a consistent state, because everything you see is rendered with the same value everywhere on screen.

Finally, in the fourth panel the store is able to update. This is because React finished, and allowed other work to happen. If the store updates when React isn’t rendering, then the next time React renders the tree, we’ll start over from the first panel, and all of the components will get the same value.

This is why, before concurrent rendering, and in most other UI frameworks, the UI is always rendered consistently. This is the way React works through React 17 and by default in React 18 when you do not use a concurrent feature.

Concurrent rendering

Most of the time, concurrent rendering results in a consistent UI but there is an edge case that can cause issues under the right conditions. To see what can happen, see the next figure.

We start the first panel the same as before, and render the component blue.

Here’s where we can start to differ.

Since we’re using a concurrent feature, we’re using concurrent rendering and React can stop working before it’s done, “yielding” to other work. This is a huge benefit for responsiveness because the user is able to interact with the page without React blocking them. In this case, say a user clicks a button that changes the store from blue to red. This wouldn’t have even been possible to handle before concurrent rendering. The page would just seem paused to the user, and they couldn’t click anything. But with concurrent rendering React can let the click happen so the page feels fluid and interactive to the user.

A consequence of this feature is that user interactions (or other work like network requests or timeouts) can change the values in the external state that are being used to render what you see on screen. This is the edge case that can cause issues. In the second panel, we see that React has yielded and the external store has changed based on the user interaction.

The issue it that first component has already rendered blue (because that was the value of the store at that time), but any component that renders after this will get the current value, which is now red. In the third panel, that’s exactly what happens. Now, the components that access external state render and get the current value, which is red.

Finally, in the last panel we can see that the component which were previously always consistently blue are now a mix of red and blue. They’re displaying two different values for the same data. This edge case is “tearing”.

Related posts

• Concurrent React for Library Maintainers

[dai-shi]

👍 Thanks for the nice explanation, Rick. (I added a link from my repo.)

[eps1lon]

Could also go in #70 but I feel like "What is tearing" is currently missing an example of a teared UI that can already be observed using just hooks in React 17. But maybe this isn't tearing?

I see a particular pattern with useEffect and useState from time to time that does lead to tearing as far as I can tell: deriving state from props in useEffect.

The code I'm going to describe already tears in React17 and can be rewritten to avoid tearing (and make it more reasonable in general IMO). I only want to point this out since it seems to me that you're creating a false sense of security by saying "only other libraries can cause tearing". Though the tearing already happens without concurrent rendering anyway.

function Input({ disabled }) {
  const [focused, setFocused] = React.useState(false);

	React.useEffect(() => {
		if (disabled && focused) {
      setFocused(false);
    }
  }, [disabled]);

  // focus handler

  // markup goes here
  return ...
}

The tearing arises when the Input is focused but becomes disabled. The consistent state would be to paint it as not focused and disabled. But due to how we modeled the state, React will create one commit with focused+disabled (inconsistent) and the next commit with not focused+disabled.

Now this example is fairly obvious. Without going into a discussion what the correct model would be or if you need to use useState at all, I would just propose to skip the useEffect entirely since this a prime example of "How do I implement getDerivedStateFromProps?".

A similar faulty implementation can be applied to your tree illustration:

function Tree({ color }) {
   const [items, setItems] = React.useState([{ color, selected: false }, { color, selected: false }]);

		React.useEffect(() => {
			setItems([{ color, selected: false }, { color, selected: false }])
    }, [color])

   return (
     <div>
      <p>Data is {color}</p>
      <Items items={items} />
		 </div> 
   );
}

When changing the color, one paint would contain "Data is red" with all items being blue (inconsistent). The next paint would contain "Data is blue" with all items being blue (consistent).

I suspect that the reason for using useEffect to set the state instead of setting it during render is that people are under the impression that setting state during render is a side-effect. It may also be problematic because the state is handled in another component and you wouldn't be able to set it during rendering of a child (see "Cannot update a component from inside the function body of a different component.").

Concrete examples (ordered by how obscure the "derived state" pattern is, starting with less obscure):

1. [ButtonBase] Derive state on render instead of in layout effects mui/material-ui#26762
2. https://github.com/mui-org/material-ui/blob/b17145cb2161d3b75293d2e8f73983754802fffb/packages/material-ui/src/InputBase/InputBase.js#L334-L338
3. [lab] Reflect draft pattern of picker value in implementation mui/material-ui#24367
4. Checkbox column appended instead of prepended in concurrent mode mui/mui-x#1562
5. [Popper] Refactor to more commonly known react patterns mui/material-ui#16613

[eps1lon]

@eps1lon When you say "derived state from props" do you mean it specifically has to be a value stored in state, or just "a value derived from props"?

A value stored in state i.e. a value that is passed into setState that is based on props.

Though this also applies to "derived state from context" or even "derived state from state". But I can't say I ever saw any of those two patterns.

[bvaughn]

@eps1lon Why is storing that value in state necessary?

I ask because it has a few downsides:

1. Requires restarting the render (so it "wastes" some work)
2. Potentially persists longer than intended (see this blog post which you may have already read)

derived state from state

I don't think I understand this pattern.

[gaearon]

Should we move this to a separate discussion thread? This seems to move further away from tearing.

[eps1lon]

derived state from state

I don't think I understand this pattern.

This was just hypothetical.

[eveningkid]

But maybe this isn't tearing?

As pointed out by others, I also believe this isn't tearing.

I believe it's called an effect as in a side-effect, which even in English means something that comes after, not at the same time.

This means that what's inside an effect, could cause changes to happen later, not in the current iteration.

Given your example, it makes sense to keep two paints:

• t: One for the props change
• t+1: One for the state update inside the side-effect

And as @rickhanlonii mentioned, if you don't want this behavior, then switching to a layout effect or derived state from props would be more appropriate.

[huozhi]

Great explanation! I have some questions related to the terms mentioned above expecting more clarification.

Q1 - external state

If user sync state from props in class components to class properties, will thoes properties be considered as a external state?
e.g. what styled-jsx used to cache props here. Guess this would be considered as unsafe external state and side effects in concurrent rendering?

Q2 - React Yield Behavior

For class component lifecycles, which ones would be also discard when react yield to something else during rendering?
e.g.

render 1 <--> render 2 <--> ... <--> render N

When react try to dedupe some render results and update with the latest one, render() methods will be definitely skipped I guess. Will other lifecycles before it like getDerivedStateFromProps also be skipped or it will still be executed? If it will be skipped, having some side effects inside getDerivedStateFromProps won't take effect right?

[huozhi]

Sorry not to make it clear here. Yes you're right they're all in render phase. The problem is more like the concurrent unsafe usage when retrieving CSS style by class properties rather than react state.

Previously, it use render + shouldComponentUpdate + class properties (this.prevProps) to handle CSS injection. In that case class properties assignment this.prevProps = this.props is mutation during rendering considered as unsafe.

Each ID represents a style

• render mount render - add ID
• render update render - update ID
• componentWillUnmount unmount - remove ID

The update render phase may have multiple ones in the transition, i.e. if it updates 1000 times and most of them are been discarded, then the class properties might be not euqal to the react internal state. Final remove in the unmount lifecycle will break the code.

After changed to using getDerivedStateFromProps, it can clone props to state which is inside react. Then the CSS style reference counting can also be safe in other lifecycle like componentWillUnmount. Retrieving styles by react state will be safe under concurrent mode.

[gaearon]

(Not sure if you saw my last reply, we posted at the same time. The issue I'm seeing is a side effect in getDerivedStateFromProps, which is similar to having a side effect in render. Since getDerivedStateFromProps is not a guarantee that old component output will be removed from the screen, I don't understand why it would be OK to remove styles there.)

[huozhi]

Yes I saw it, thanks for the kind reminder. I'd like to explain more about it:

ThegetDerivedStateFromProps will either add style or update it. The componentWillUnmount will finally remove it.

When the render gets interrupted (I'd expect getDerivedStateFromProps is either executed or not), the old style is still in the state and finally can be erased in unmount phase. The key point is to safely remove the existing style when unmount it.
But if the style is removed first and not been update yet, at this moment render gets interrupted then it would be totally unsafe (getDerivedStateFromProps only gets executed partially). I'm not sure will it happen in react 18? If there would be a case like this I think my solution is not a safe one here.

Regarding to why putting this effect in render phase: I agree that we'd better not to have any DOM side effects in any render phase before committing. Previously they want style be injected earlier so that it will display more consistent (rather than keep old style, update component then render new style).

Thanks again for your patient follow up 🙏

[gaearon]

We briefly discussed this in a team meeting today. So far my understanding is:

• Render phase (whether render, getDerivedStateFromProps, etc) isn't a good place to remove styles because there's no guarantee that this particular render will get committed next. So you might be removing a style that's in use. As a workaround to unblock testing, we suggest to not remove styles at all.
• They're an OK (but not ideal) place to add styles. Note that this is not great for performance because it still causes unnecessary relayouts (Fix JSXStyle renders styles too late vercel/styled-jsx#484 (comment)).

As for an ideal place to do this, we will be revisiting this problem space at some point closer to the Beta. We might have to add some new Hook or a place to do this which doesn't suffer from the above issues.

[gaearon]

The getDerivedStateFromProps will either add style or update it. The componentWillUnmount will finally remove it.

I don't feel like I understand this pattern. Looking at the code, doesn't this remove it?