With the introduction of the new, still experimental feature, the developers behind the framework are following findings from human-computer interaction research.
As things stand, React blocks the rendering of other components if another rendering process is already in progress. A wonderful analogy, which the React documentary also cites, is Version Control. If you work with several people – or alone – on a project, you are most likely using Git or another version control system. You work in branches. When a feature is ready, you merge it into the master branch and the others can pull. So far, so state of the art. Before version control systems like Git, developers wanted to change something to the files within a project, instruct their team members to stay away from the project until they had implemented the change. The entire development process was blocked for the change period.
This is roughly how you can imagine the rendering process of today’s UI libraries. As soon as an update is rendered, for example new DOM nodes are created and code is executed within components, the library – for example React – cannot stop this process.
Renderings that have already started can be interrupted
What makes the concurrent mode features so revolutionary is that they make the rendering process interruptible. This should improve the user experience significantly. If the user makes an input when using a React app in the future, React will no longer keep the browser from updating the input until the previously started rendering process has been completed, but can update the input quasi switch between and continue rendering the updated list in the background. Then React updates the DOM and the user sees the changes on the screen.
Conceptually, you could imagine it as if React were preparing each update on its own branch: You can simply leave a less important feature behind and continue with something else.
The concurrent mode reduces the need for debouncing and throttling the UI. You no longer have to artificially hold up renderings to prevent sluggish interfaces. They start immediately, but can be interrupted at any time if necessary.
Build-in intentional loading sequences
The following scenario: The user navigates between two screens in an app. Sometimes there may not be enough code and data loaded to indicate a sufficient charge status to the user. Switching to a blank screen or seeing a weirdo forever sucks. A more elegant solution is to stay on the initial view until enough data and code have been loaded to also display the second completely. This is possible, but not that easy – at least so far: With Concurrent Mode, this feature is the default. React prepares the new screen in the background – if you want to stick to the Git metaphor: on a new branch – while the initial screen is completely retained. The change to the new screen will only take place when your app is ready.
For CPU-bound updates such as creating DOM nodes or executing code, Concurrent Mode means that a more urgent update can interrupt a less important rendering. For IO-bound updates, like fetching code or data from a network, concurrency means that React starts rendering in memory before all data is available. In the meantime, the user is shown the previous screen instead of an empty screen or spinner. Concurrent mode won’t change the way you outstaffing work with React. Components, state and props work exactly as they did before. If you want to update the view, you set the state. React uses a heuristic to decide how “urgent” an update is, but you can adjust it as required with a few lines of code.
TLDR: Concurrent mode is about priorities. According to the status quo, React cannot interrupt a rendering that has been started. With Concurrency Mode, React keeps an eye on things that are otherwise pending: If there is something with a higher priority – for example another update or other tasks that the browser has to perform – React will prefer this in the future. The prioritization is based on findings from human-computer interaction research: interactions such as text input must take place in a relatively short time, with clicks or page changes the whole thing can take a little longer without us as users having the feeling that this is going to take a long time Long.
Attention: The innovation is still in the so-called Experimental State! The documentation strongly advises against using the new feature in your projects now. The whole thing is now available to try out for the curious and those keen to experiment – specifically in a framework in which you cannot really break anything. If you like to experiment and want to test it now: Have fun!
For further reading: