Concurrent React Mode: Using Suspense and useTransition to Build A Better UX

Photo by Irvan Smith on Unsplash

The React JS dev team announced some exciting changes several months ago - React would be getting a "Concurrent Mode". Essentially this would allow React to perform multiple UI renders concurrently. Of course, JavaScript is single threaded and true concurrency is an illusion, but the new features will allow web apps (and Native Apps once these features hit React Native) to be much more responsive and snappy than they are now with less effort and custom code from the developer to make this happen.

Concurrent mode is now available in the experimental build of React, so let's dig in and see how to use the shiny new API.

Suspense

useTransition

useDeferredValue

But what about the existing Suspense feature?

Suspense

React.lazy()

The New Way - Render as you fetch

This has been discussed a lot through talks and blogs and in the official documentation already, so I'll keep it brief - Concurrent React allows us to implement a "render as you fetch" pattern, which renders components as the data needed to populate them are fetched concurrently. React renders as much as it can without the available data, and renders the component that requires the fetched data as soon as the data becomes available. During this time these components are said to be "suspended".

The commonly used existing approaches are "fetch then render", which fetches all the data needed first before rendering the component, and "render then fetch" which renders a component and then the component itself fetches the data required to populate it's children. Both these approaches are slower and have a number of disadvantages that needed workarounds.

The Setup

For this, I'm using a basic React app I configured manually with Webpack and Babel ( Click here for a guide I wrote on how to do that ), with the only difference being running:

npm i react@experimental react-dom@experimental --save

react

react-dom

create-react-app

react

react-dom

Opting in to Concurrent Mode

ReactDOM.render()

index.js

ReactDOM.createRoot(document.getElementById('root')).render(<App />);

This enables concurrent mode in your app.

App.js

Data

import React from 'react';
import Data from './Data';

const App = () => {
    return (
        <div>
            <p>React Concurrent Mode testing</p>
            <Data />
        </div>
    );
}

export default App;

The Demo

Data.js

import React, { useState, useTransition, Suspense } from 'react';
import DataDisplay from './DataDisplay';
import { dataFetcher } from './api';

const initialData = { read: () => { return { foo: "initial" } } };

const Data = () => {
    const [data, setData] = useState(initialData);
    const [count, setCount] = useState(0);
    const [startDataTransition, isDataPending] = useTransition({ timeoutMs: 2000 });

    const fetchNewData = () => {
        startDataTransition(() => {
            setData(dataFetcher())
        })
    }

    return (
        <div>
            <Suspense fallback={<p>Loading...</p>}>
                <DataDisplay data={data} />
                <button disabled={isDataPending} onClick={() => fetchNewData()}>Click me to begin data fetch</button>
            </Suspense>
            <p>Counter: {count}</p>
            <button onClick={() => { setCount(count + 1); }}> Click me to check if the app is still responsive</button>
        </div>

    )
}

export default Data;

Breaking this down:

dataFetcher

initialData

dataFetcher

read

initialData

{ foo : "initial" }

useTransition

useTransition

This is useful in cases when showing stale data till new data is loaded is desirable, and also to prevent the spinner from showing up for a fraction of a second (causing what is percieved as jitter) on fast data fetch operations.

Suspense

<Suspense fallback={<p>Loading...</p>}>
    <DataDisplay data={data} />
    <button disabled={isDataPending} onClick={() => fetchNewData()}>Click me to begin data fetch</button>
</Suspense>

Suspense

fallback

isDataPending

Talking about the page remaining responsive - it does. All the JavaScript in the page continues to work while the component is suspended and data is being fetched. The counter and the button to increment it can be used to confirm this.

DataDisplay

import React, { memo } from 'react';

const DataDisplay = ({ data }) => {
    return (
        <h3>{data.read().foo}</h3>
    )
}

export default memo(DataDisplay);

memo

dataFetcher

api.js

export const dataFetcher = (params) => {
    return wrapPromise(fetchData(params))
}

const wrapPromise = (promise) => {
    let status = "pending";
    let result;
    let suspender = promise.then(
        r => {
            status = "success";
            result = r;
        },
        e => {
            status = "error";
            result = e;
        }
    );
    return {
        read() {
            if (status === "pending") {
                throw suspender;
            } else if (status === "error") {
                throw result;
            } else if (status === "success") {
                return result;
            }
        }
    };
}

const fetchData = (params) => {
    // In a real situation, use params to fetch the data required.
    return new Promise(resolve => {
        setTimeout(() => {
            resolve({
                foo: 'bar'
            })
        }, 3000);
    });
}

dataFetcher

wrapPromise(fetchData())

fetchData()

fetch()

fetchData()

params

setTimout

Promise

{ foo : 'bar' }

wrapPromise

Promise

All of this put together results in this:

Initially the data shown is "Initial". Then I click the button to begin data fetch. According to our configuration, the button is disabled immediately and nothing happens for 2 seconds. Then the component suspends, showing the fallback "Loading...". Then finally the data fetching is completed and the component updates to show "bar". During this whole time the remaining app (shown by the counter here) remains active.

Suspense

useTransition

Conclusion

api.js

But it is expected that soon leveraging concurrent mode will be the de-facto way to get around lengthy operations in UI, allowing the creation of user experiences that remain consistent across many devices with vastly different processing powers and network connectivity speeds.

• You can find all the code used in the demo here.
• You can find me on Twitter and LinkedIn .