TL;DR 🚀 Concurrent rendering addresses the performance problem with rendering large UI updates while keeping the UI responsive. 🧑‍🔬 We'll use 3D rendering in the browser to stress test React 18. ⚖️ We'll look at the typical approaches alongside concurrent rendering and discuss their pros and cons. In this article, we are diving into a 3D visualization and discuss how to optimize its performance step by step with React 18's concurrent rendering. Here's the sneak peek. Concurrent Rendering with useTransition . The core idea is to classify state updates into two categories: React 18 introduces the concurrent features : they provide responsive feedback to user interactions, like typing and clicking. Urgent updates : they provide non-urgent UI transitions, like displaying dataset. Transition updates The purpose is to create a snappier and more responsive experience for the users. Before React 18, all updates are considered urgent, and a simple click or typing can cause the screen to freeze when there's a larger rending. So in React 18, by deferring non-urgent updates to urgent updates, users are able to receive immediate feedback from their interaction while React is working on the non-urgent updates in the background and reflect the result when ready. According to the working group, the concurrent rendering is able to perform the following things: : React will periodically stop working and let the browser fire one or more side effects. Yielding : When React detects new urgent updates, it will interrupt and pause non-urgent updates and start working on incoming urgent updates so the page can stay responsive. Interrupting : React will discard outdated transition updates and only render with the newest state. Skipping old results We’ll use the format and methods from the articles to test the 3D rendering demo and observe the impact on the performance and user experience. 3D Rendering Demo Overview In order to create heavy computations for rendering, I built a 3D visualization to show the connections between a GitHub user and the users she's connected with on GitHub. The technology includes: three.js react-three-fiber React 18 The UI looks like this: The components we will be discussing today includes: : to search for a GitHub username and fetch the user info from the GitHub GraphQL API. Search Bar : to visualize the connections between the user and her connections in on a 3D globe. Scene You can find the repository on GitHub and the demo on Netlify . Please note that the demo might crash due to a task timeout. The timeout is caused by the slow experimental API call to fetch the coordinates of the cities. If you'd like to interact with the demo, it's recommended to fork the repository and run the development server locally. As we type into the search bar, you'll see an increasing amount of stars in the scene to simulate the high rendering demand on the UI. The amount of stars is . We'll use it to stress test concurrent rendering. 100,000 * inputValue.length The Problem Let's start with our base case with the most basic implementation. The outcome looks like this: You can see my typing on the bottom left corner of the video. As I was typing, the search bar was frozen. It didn't display the input value until the very end. Not just the search bar, the scene was frozen too. The stars didn't get rendered until I finished typing. Ideally, we want to be able to observe immediate feedback from our typing. Let's look into the performance together. We'll slow down the CPU by 4x and run a performance profiling. You can see the big chunks of tasks with keypress event in the flame chart. With each keypress, React computes the next rendering for the SearchBar and the Scene. As we see in the chart, the longest task takes almost 0.8 seconds to complete. That's why the page feels so slow. So, what's happening? In the Home page component, the SearchBar listens to the keypress event and update the username when changes happens. setUsername(username)
  } )
} const Home: NextPage = () => { const [username, setUsername] = useState< string >( '' ) const vertices = useMemo( () => computeVertices(username.length), [username]) const handleChange = ( username: string ) => { return ( <> < SearchBar value = {username} onChange = {handleChange} /> < Scene vertices = {vertices} /> </> Whenever there's a username update, React recomputes vertices by calling computeVertices() and pass the result in to the Scene component to render the stars. Since the number of vertices is 100,000 * username.length, coupling the two state updates together is a very expensive rendering cycle. How Did We Fix It Before React 18? Ideally, we want to see what we typed in the search bar immediately. Knowing that updating both states in the same rendering cycle takes too long, we can simply split the two updates so that SearchBar and Scene gets rendered separately. Let's first add a new state for the SearchBar: } setValue(value) onChange(value)
  } } setUsername(username)
  } )
} type FastSearchBarProps = { defaultValue : string onChange : ( value: string ) => void function FastSearchBar ( { defaultValue, onChange }: FastSearchBarProps ) { // new state designated to SearchBar const [value, setValue] = useState(defaultValue) const handleChange = ( value: string ) => { // update input value // update vertices return < SearchBar value = {value} onChange = {handleChange} /> const Home: NextPage = () => { const [username, setUsername] = useState< string >( '' ) const vertices = useMemo( () => computeVertices(username.length), [username]) const handleChange = ( username: string ) => { return ( <> < FastSearchBar defaultValue = {username} onChange = {handleChange} /> < Scene vertices = {vertices} /> </> Now we have a value state for SearchBar and a username state for computing vertices. We'll need additional work to separate the renderings because React will batch the state updates together in the same event to avoid additional rendering. Let's take a look at some of the typical approaches. Approach #1: setTimeout We can simply defer the slower update by adding setTimeout to put the it in the event loop. setValue(value) onChange(value) } } function FastSearchBar ( { defaultValue, onChange }: FastSearchBarProps ) { const [value, setValue] = useState(defaultValue) const handleChange = ( value: string ) => { setTimeout ( () => { }, 0 ) return < SearchBar value = {value} onChange = {handleChange} /> Now even with the 4x slowdown, the SearchBar looks more responsive. We also observed that the stars are getting rendered while we were typing. If you take a look at the performance profile, you can see that we were able to separate the keypress events from the expensive tasks. However, we noticed that the Scene was rendered twice after the last keypress event. That's because the renderings were still scheduled with outdated state when the setTimeouts were fired. Approach #2: Debouncing We can actually cancel the rendering schedule by implementing debouncing. setValue(value) onChange(value) } } function FastSearchBar ( { defaultValue, onChange }: FastSearchBarProps ) { const [value, setValue] = useState(defaultValue) const timeout = useRef<NodeJS.Timeout>() const handleChange = ( value: string ) => { // cancel the schedule if `value` changed within 100ms. clearTimeout (timeout.current) // schedule a new update if input value hasn't changed for 100ms. timeout.current = setTimeout ( () => { }, 100 ) return < SearchBar value = {value} onChange = {handleChange} /> The user experience looks better now. The SearchBar stays fairly responsive with 4x slowdown and the redundant update on the Scene after the last keypress event was gone. However, the shortcoming of debouncing in this case is that the Scene update will always be delayed by 100ms. With faster CPU, the delay is most likely redundant and it makes the page feel slow. React 18's Concurrent Rendering: startTransition The page feel more responsive with either adding setTimeout or debouncing, but they introduces different problems: setTimeout: results in additional UI updates with outdated statesdebouncing: results in artificial delay in UI updates Let's take a look at how React 18 solves the problems with concurrent rendering: type FastSearchBarProps = { } setValue(value)
    onChange(value)
  } } [username]
  ) setUsername(username)
    })
  } )
} import { startTransition } from 'react' defaultValue : string onChange : ( value: string ) => void function FastSearchBar ( { defaultValue, onChange }: FastSearchBarProps ) { const [value, setValue] = useState(defaultValue) const handleChange = ( value: string ) => { return < SearchBar value = {value} onChange = {handleChange} /> const Home: NextPage = () => { const [username, setUsername] = useState<string>( '' ) const vertices = useMemo( () => computeCoordinates(username.length), const handleChange = ( username: string ) => { // defer username update in a less urgent UI transition startTransition( () => { return ( < Container > < FastSearchBar defaultValue = {username} onChange = {handleChange} /> < Scene vertices = {vertices} /> </ Container > We call setUsername inside of startTransition function. It tells React to defer setUsername to the other urgent updates. As you can see, we are able to separate the rendering of SearchBar and Scene without any asynchronous functions. If we take a look at the performance profile, we can observe a few things: The keypress events are separated from the long rendering function calls. The keypress events are grouped. It aligns with the behavior in concurrent rendering. yielding There's only one rendering call after the last group of keypress events. It aligns with the behavior in concurrent rendering. skipping old results The behavior is not very straight forward to observe. If you know how to analyze it from the performance profile, please feel free to ! interrupting reach out to me on Twitter Let's remove the slowdown and see the final result: Final Thoughts In the past, adding debouncing was the go-to solution for rendering large UI updates while keeping pages responsive. Based on this experiment, concurrent rendering makes the UI more responsive without the shortcoming of debouncing. Even for the heavy computation with at least 100,000 3D objects, concurrent rendering still helped the page to be snappy. Here's the side-by-side comparisons: UI Comparison with 4x CPU Throttling Basic implementation without concurrent rendering: Optimized implementation with concurrent rendering: UI Comparison with No CPU Throttling Basic implementation without concurrent rendering: Optimized implementation with concurrent rendering: References GitHub: Demo repository Website: Demo Site Website: React v18.0 GitHub: New feature: startTransition GitHub: Real world example: adding startTransition for slow renders GitHub: three.js GitHub: react-three-fiber Website: WebGL Globe Solution This article is originally posted on . Daw-Chih's website

Alongside

Fetch

Twitter

Writing an Event Bus for React

Static Full-Text Search in Next.js with WebAssembly, Rust, and Xor Filters

Check out my website!

Nominated for 2022 - HackerNoon Contributor of the Year - Product Management

Nominated for 2022 - HackerNoon Contributor of the Year - Typescript

Nominated for 2022 - HackerNoon Contributor of the Year - Leadership

Nominated for 2022 - HackerNoon Contributor of the Year - Software Engineering

Nominated for Coding Guru of 2022

Nominated for 2022 - HackerNoon Contributor of the Year - Learning

Too Long; Didn't Read

Make resilience your competitive advantage

React 18's Concurrent Rendering for Stress Testing: A 3D Rendering Case Study

React 18's Concurrent Rendering for Stress Testing: A 3D Rendering Case Study

About Author

Comments

TOPICS

THIS ARTICLE WAS FEATURED IN

Related Stories

Untitled Story

Enhancing Test Stability with Fixtures in Rust

Top 10 JavaScript Charting Libraries for Every Data Visualization Need

10 Data Table Libraries for JavaScript

10 Best React Native Chart Libraries

10 Best Datasets for Time Series Analysis

Enhancing Test Stability with Fixtures in Rust

Top 10 JavaScript Charting Libraries for Every Data Visualization Need

10 Data Table Libraries for JavaScript

10 Best React Native Chart Libraries

10 Best Datasets for Time Series Analysis

Light-Mode

Classic

Newspaper

Dark-Mode

Neon Noir

Minty

HN StartUps