Staying Safe In a Concurrent World

♪♪ Hello, everyone. I hope you're having an awesome conference so far. Maybe you even heard a couple of talks or visited some workshops or did some discussions outside there about the new concurrent features that were released in the newest version of React.

In this talk, I want to talk about exactly those features, but I don't want to showcase the APIs, the concrete APIs, but I'd rather focus on the ramifications and implications those features have on you as application developers.

Before we are going to jump into that, I like to introduce myself first. My name is Andreas and I'm a development lead at a small agency in Dresden and our job is basically to go into the project of other teams and help them make their code better, make their software work better, make their development process faster. In this process, we talk to lots and lots of developers from different teams and we noticed that there are more or less like two groups of developers. One group hasn't yet heard of the concurrent features and is doing something wrong in the application that might break when they use concurrent features. The other group is not using concurrent features because they are afraid something might break in their applications. So, many of them still aren't really using them.

And this is why I today want to tell you a bit about those new features to make sure that you can stay safe in a concurrent world. To get started, we first have to jump back a couple of years when Dan Abramov revealed the new vision for React. Back then, this feature was still called async rendering. The goal was to adapt to the user's network and to the user's device, so that even on smaller devices, the application could still feel responsive. And when the device is fast enough, that everything happens instantly without having any superfluous timeouts that you might not need in your applications.

Since then, lots has changed. For example, the release date. As you know, we don't have 2018 right now, so we had to wait a couple of years more. And many different topics changed as well. For example, the name. Back then, this was introduced as async rendering, or async react. It was then a bit renamed to concurrent mode or concurrent react, and then the team made the awesome decision to drop the mode so that you don't have to opt in your whole application into this new world. But they released concurrent features so that you as developers have the full control when the new behavior of react is used in your application and when not.

Back then, they even released this blog article where they made some preparations for this new feature. So, for example, they renamed some of the life cycle methods like component will mount, component will update, because they already knew that these functions were not safe for concurrent mode. They had to make certain adaptions because they knew where they were going, they knew their vision. So you could say in some sense that react has changed. But this is not true. This is the most important point of my presentation today. The rules of react have not changed.

The core premises and the core rules that we have to stick to as developers are still the same as back then in 2016. So the rules of react have not changed. We only start to really make use of them now. So all those years, we had to stick to some basic concepts like purity and no side effects without any real benefit. But right now, the framework starts really using that we are complying with these rules so that we can improve our applications.

You can see that from this design document. This is from more than seven years ago. And in here, it says that the core premise for the React library is that react itself is a projection that takes some data as an input and transforms that into an output so that your application is a simple pure function. So with the same input, it should always result in the same output. But since React didn't really use these rules in the application, they have been developing a couple of misconceptions around the React rendering model. And the first one is that the reconciliation phase of React is atomic.

Let me explain what reconciliation means. So whenever React updates, there happen two phases. At first, there's the reconciliation phase. So React calls your function components, generates those JSX elements, gathers them all together, and compares them to the previous version. This is the colloquial called virtual DOM. And then in the second phase, the commit phase, React is taking all those differences and applying them to the real DOM that we see as users in the browser. And back then, in the earlier architecture, it was a guaranteed that the reconciliation phase is always atomic because it was implemented that way.

Back then, we had the stack reconciler, that means React went through your application, through your components, started with the app component, then the app component renders the main component, so the reconciler went into this main component. So we have this stack inside of the React library that went through your application in an uninterruptible manner. So whenever React started with working on your app component, it could only do something else once everything else is finished. With the release of React 16, React changed this architecture to the fiber architecture. So we no longer have this stack of components inside of our application, but React internally keeps a list of components and can traverse this list iteratively and even interrupt this process. That means in the meantime, the event group and the browser has some air to handle user events. So the user scrolls, for example, but React is doing some calculations. React can pause those, handle the user event, update the user interface, or do something else, send some requests or something like that, but the reconciliation phase can now be interrupted and won't happen atomically. It's very important to note that it was never guaranteed that the reconciliation phase is atomic. It just happened to be that way because of the implementation. So relying on that was us relying on implementation details which now leads to problems. And for that I have a small demonstration application.

So let's clear the console right now. What we have here is a simple React application where we have three blocks that display some state. Whenever I click on this re-render button, some state is updated and you can see in the console that the rendering is artificially slowed down. Each component takes something like five seconds to do its reconciliation phase, and then the commit can happen and we can see the update in the user interface. And even with React 18, this process is by default still atomic.

So when I click this re-render button and click on the change global state button, I'm just meshing that button until the rendering is done. Then we can see the reconciliation just happened as one large chunk, as one atomic unit, and only after that is done, can React handle the clicks that are made on the button. But now, with the concurrent features, this changed. So I have now the possibility to schedule a low priority update. So let's click on that button and mesh the change global state button. As you saw, we saw between those two components, the first block rendered up here. And then after this reconciliation phase of the first block, React had time or yielded to the browser. So the browser could inform us, yeah, there was some click events. So React could update this global state. And then after that is handled, React continued the rendering process with the next components, so with the second block and then with the third block.

This process is a bit non-deterministic because the browser decides when it's time to do what, so it's a bit hard to really showcase that. Sometimes the changes will happen between the second and the third component, sometimes both, sometimes the reconciliation still happens atomically. But we can see now that we no longer have this guarantee that the reconciliation phase is atomic. And we can already see the first problem. If we zoom in a bit here, we can see the first block rendered with a state of 26, the second block rendered with a state 35 because in the meantime I clicked the button 10 times, so the other components suddenly showcase a different state that is no longer up to date. So you get this tearing effect, so you see two different versions of your application, two different versions of the state within the application.

So we need to change something in our code so that this doesn't happen. And what we need to do is we need to stop reading values that might change outside of the React world, so no more reading some values that can change without React being able to know that they changed. This means we can no longer read global variables that are mutable. So for example, in my example, this global state is just a module level variable defined with let, and this is updated with the event handler. And we are reading this in the component, but React is just not able to know that someone changed this simple variable. For that we'd have to use the useState or useReducer hook. So we need to stop doing something like that where we read some global values inside of our component because these values might change during the reconciliation phase because it's no longer atomic. Same goes with reading refs. So refs are specifically made for objects that can be mutated around React without React having to react to that.

So whenever we read a ref during the reconciliation phase, so for example, inside of the JSX, we might run into the same problem that the user interface shows different versions of the state. And the same thing goes whenever you feel like implementing your own Redux in 20 lines, for example, and you just read the global state from your custom state management solution. This is just the same problem. As long as this solution is not really integrated into React, then we might run into problems.

Let's come to misconception number two. It's that one reconciliation phase or one render always leads to one commit. So what we saw earlier, we have this reconciliation phase and then when this is done, then we have the commit phase. So only then is the user interface updated. So even if we split up the reconciliation phase, we still have the guarantee from React, and this is a guarantee that the commit phase is atomic because React doesn't want to display different versions of the state. React wants to showcase a consistent view of the state of the application. So the commit will always be atomic, but the reconciliation can have pauses in between.

And we now have the problem that we no longer have the guarantee that one reconciliation phase always leads to exactly one commit phase. You already heard about that earlier today from the talk from Nick, where he told you that with React's strict mode, React renders your components twice. So React already runs your reconciliation phase twice for only one commit phase. Now in the strict mode, there are even two commit phases. But this already breaks this combination that you have always one reconciliation phase and one commit phase. And we can also take a look at that inside of our demonstration. Let's first hide the blocks that we have available here and tick this checkbox that we want to display the commits. And now we are going to show the blocks. This will take again, 15 seconds, five seconds per block. And then before this is done, we are going to click the button to hide the blocks again. I'm clicking the Show Block and now I'm spamming the Hide Blocks button just so that it happens as fast as possible. We can see the reconciliation phase since I just scheduled a normal update. This is still atomic so we still go through all of the three blocks. The first one, five seconds, the second one, five seconds, the third one, five seconds. And then the commit happens. So, for a brief moment that was not really visible on the screen, but for a brief moment, the DOM contained those three blocks only for React to update once again because we clicked the Hide Blocks button to completely remove the elements again. So here we can see we have reconciliation phase and we have an update phase. Everything looks fine. But now when we use the low priority features from the concurrent features from React, we're clicking Show Blocks Low Priority and now spam again Hide Blocks.

And we can see the process is aborted. So only the first element was reconciled and then React stopped because React had time to handle the event, the click on the other button that changed the global state to hide the blocks again so that React knew, okay, we don't even need to render those other elements. Completely aborted this process so that the blocks were never visible in the user interface. So there we had a reconciliation phase on the first block without any commits. So whenever we rely on the fact that React will commit after reconciliation phase, we are prone to errors in our applications. That means again that we need to change our behavior. We need to stop subscribing or mutating the outside world within the renderer function, within the reconciliation phase. So again, our components have to be pure functions that don't read from the outside world if the outside world can change and we are not supposed to mutate the outside world within the reconciliation phase.

For this I also have a couple of examples. So for example, there are some libraries out there that register event listeners or register subscribers to some state management solution and they do that during the rendering process. So here we have this fictional component that creates a listener during the rendering phase and directly adds that to the window object. Now imagine this component never unmounts, then this listener will just be stuck on the window object and no one will ever remove that, so we have a memory leak introduced to our application. Luckily, this problem does not really occur too often in applications.

This is more happening in library code and so whenever you stick to popular libraries, you won't really run into that problem, but it's still important to keep an eye on that, that you don't mutate the outside world, don't build up a connection, don't create web sockets and stuff like that because this might break when we use concurrent features. However, it still has to be possible somehow to do these things, to read from global values, to mutate the outside world, because in the end, our application is made to communicate with a server, to communicate with the user, to display some changing state, so there have to be some solutions.

The first one is to just move all of this communication inside of UseEffect because UseEffect is made that we have the build up, so we can make a connection at event listener and stuff like that, and we have the cleanup, so we just return another cleanup function from the UseEffect and can clean up if we build some connections, so we add an event listener and then we remove it again when the component is unmounted. And since we always have this guarantee that there will always be a cleanup after the UseEffect call, it's safe to do something like that inside of UseEffect. So we always have this pattern that you have a state variable inside of your component, you read from the server inside of UseEffect, update the state variable, and then you're good to go. The problem with that is that during the first reconciliation phase, the effect has not been called yet, so whenever you require to display something from the UseEffect call, you have to do the first reconciliation phase without this value because it will only be present in the second phase when the state has been updated.

So the second option is to pick a library that fits your use case. If you pick React Query to do communication with the server side, if you pick something like Redux Toolkit to handle your state management solutions, you can pretty much rely on the popular libraries to already be concurrent-mode safe or concurrent-feature safe because React team has been working quite closely with the maintainers together in this RFC process so that these libraries are already concurrent-mode safe. And the third option is if you really want to handle your own solution is to use useSyncExternalStore. This is a hook that React provides us that we can use to sync our application with some external data. For that, you first have to define a subscribe function, but you again have this notion of a buildup, a constructor, so to say, and to cleanup where you have to guarantee that these will always run in pairs. So here, for example, we add an EventListener to the global resize event and we make sure to remove that again once this sync process is cleaned up by React. After we did that, we can build a custom hook, use windowWidth, for example, and use the hook useSyncExternalStore where we pass in our subscribe function as the first argument, and the second argument is the value that reads from the outside world. And now React can absolutely be sure to control when this reading function is called so that React can be sure that this value never changes during a reconciliation process so that the user interface always stays consistent. That way, we can use our custom hook, use windowWidth, wherever we want in our application, and can use the value during the initial render of our component and can be sure that during updates, it will stay up to date as well and not introduce those tearing issues. That means when we use one of those three options, we can just go back and relax and let React do its thing because the React team designed React in a way that we live above this abstraction level. So in the ideal world, we would never wonder how many times our reconciliation phases are called because React might make some decisions in the future to call them more often, to call them less often, to skip some or to recall them. If React is able to rely that these functions are pure, then React can decide these things for us and can make optimizations without our code breaking. So with these assumptions, it's now possible again to lean back and stay safe in the concurrent world of React. Thanks for listening. Thank you ever so much. Thank you. Thank you. Thank you ever so much. If you'd like to join me here, we've had some questions.

Just a reminder for the audience, you can open up Slido at any point and ask questions to our speakers today. We only have a couple in right now, so by all means, do ask questions. We'll probably have time to ask them. So thank you once again for your talk. I'll crack on with the first question we have, which is, what are some of the common mental models that you see in developers that lead to mutating values outside of React? I think it's just the normal way of thinking that for example, when you have a variable that you can use to display information in the user interface. The same thing goes for updates. We have a feature in JavaScript called let, and you can use that to define variables that you can change in the future, but React does not allow that, or React does not want that and probably support that. So there definitely are some learning curves. It's especially important when you're introducing React developers with other backgrounds to the React world, because you have to definitely change your mental model to come into this world where everything that changes needs to go into a use state or in a use reducer, because only then React has the full control over that.

Excellent, thank you. The next question which is having, wow, so many upvotes, so quickly. Elon Musk, I guess? Is there, don't worry, this is a lovely audience. They will only ask you the most lovely questions. Don't worry. Is there any way to lint potential issues in component usages? Yeah, definitely. And there are already many lint rules in place. For example, one of the important things are the dependency arrays. So whenever we use the effects, we need to add those dependencies so that the effect always runs at the moments where we need them to run. I guess it's also quite possible that there exist rules regarding mutations, because whenever you mutate an array, mutate an object, we can already know, okay, this breaks these assumptions about the immutable world of React. So I know definitely about the hooks rules, which are quite important. And I guess there should also be some rules regarding mutations, mutable variables, and stuff like that.

Excellent. Thank you so much. Okay, so what libraries would you recommend? You mentioned three solutions, the middle being using libraries. I know you said it was very dependent on use case. Are there any kind of first options that you might reach for to manage this synchronization? So I think the popular solutions are just for data fetching, is something like React query. We saw earlier in the TRPC talk that this is built in into many other libraries because it's just so reliable and they're handling those problems quite well. And for state management, it's just the usual contenders like Zustand, Yotai, Valtio, and stuff like that, which are just built for that because the maintainers of those are already also quite aware of the problems that might be caused by the concurrent features. So whenever you pick something that's popular and used and actively maintained, you can be sure that the team's communicated with the React team and you can rely on that, I think.

Cool. Are there any visible benefits of using concurrent mode in existing frameworks like Gatsby or Next? I'd first like to go into the detail on the first point of the question. I think it's really, really hard to showcase the benefits of that. There have been many, many Twitter discussions where that came across, where some people made some demonstrations with some cubes spinning in a div and where the framework could be maintained with concurrent features. And then other library maintainers come in and say, our library is so fast, we don't need this concurrency. So it's really, really hard to tell if there will be really some tangible, measurable benefits. The Rack team has this vision that since it's theoretically possible to schedule the rendering of the reconciliation process, that there will be benefits there, but it's really hard to showcase some examples there. But in theory, it should be quite clear that whenever the framework is able to decide what it wants to work next on, because some things are more important for the user as others, there should be some benefits there, but it's again really hard to showcase them. Regarding the integration into Next.js and Gatsby, all those features are especially important for, so these time-slicing features are especially important for the client-side rendering. So whenever you have applications that do a lot on the client-side, so some interactive charts where you can filter the data, for example, then it becomes really important that the scheduling can really show the benefits. When you have a static page that is pre-rendered with Gatsby, for example, and just displays a blog article, you probably won't notice any difference anyhow.

Yeah, awesome, thank you. And yeah, finding, you know, one of the more difficult things with building demos for these slightly more conceptual, abstract concepts is that they can be a little bit conceited, and therefore it's hard to... I think the React team also struggled with that because in the beginning, they had this Sierpinski triangle demonstration where the triangle was made larger and smaller, and they quickly realized that this only makes really sense when you add some artificial delays, like in my demonstration, because then you can see the effects of these features and you can demonstrate them, but they since moved away from that because they realized these are just really contrived examples, and it's really hard to imagine how that affects us in our applications. Yeah, forever the challenge with documentation and sample app building.

Right, we have a couple more questions. We might have time for a couple more still, so if you have questions, don't be shy. So would you enforce, or perhaps, consider banning the let key word to enforce immutability? So I personally wouldn't. I could understand if some do that. There are some people in the community that always use let because it's just three letters instead of five letters, so it's just shorter, and I think it's just a matter of preference. The longer you work with React, the more those patterns of mutations and updates stick out like a sore thumb. In a code review, it becomes quite clear, quite apparent when someone uses that, and then you can see if someone uses let, okay, what's happening here? Is that okay or not? Because there are situations where this is totally fine to lose a let variable. For example, if you have a function in a side of that function, in an event handler, for example, you want to update a variable, it's totally fine to do that as long as you don't mutate anything that is already shared with React so that React can always keep track of the data. So as soon as you share something, then you must stop the mutation and with this precondition, it's quite hard to completely ban something because there are still available use cases for doing that.

Yeah, absolutely. So this question is, would it be fair to say that working with concurrent mode now brings extra complexity when working with external libraries? I think this is one of the main complaints that have been brought up is that it seems like all of a sudden, React got a lot more complex with that. In the early days when you had those guarantees which were not really guarantees that everything happens just once and everything happens from start to finish, it was just simpler to reason about the internals of React and to include that in your features that you were developing. And now there is this new layer of complexity. Then Abolrov mentioned on Twitter that he likes to think that React is now able to render two universes at once, two versions of the state. And I think I wouldn't have come up with the idea of using a UI framework to render two universes, which I think showcases quite well that yes, it becomes more complex, but only if we really want to make use of those concurrent features, because we can also decide as a team to just don't use them, and then we are basically good to go.

Cool. This is probably the last question we'll have time for. And thank you very much to everyone who submitted. We ended up with somewhat of a surplus, and that's absolutely fine. After this Q&A, Andreas will be over in the speaker Q&A section over in the networking area. So please, if you did ask a question that we don't have time for, or if you think of more in the meantime, please feel free to head there for the next few minutes and ask us directly. So this last question, which I think is kind of a fair follow-on from some of our previous ones, is can you think of any good real-world use cases for where concurrent mode really shines? Yeah, I think one of the, so you have to have a use case where you have many different components and where each component takes a bit longer than usual. So for example, you have, to render one frame, you have 60 milliseconds. So for example, you could say you have like 1,000 components and each takes two milliseconds. This is a perfect use case because React can then go through like eight components per rendering cycle, then you to the browser make some updates and then continue with this rendering process. But these use cases are really rare because when you have a list with 1,000 elements, you first start to virtualize that list so you only render the first 10 elements that are visible. That is why I think many of the demos use something like charts because in charts, it happens quite often that you have like 1,000 data points within one chart. But then the problem is, calculating one of those data points is oftentimes quite cheap. So we don't really run into the benefits of that. Paul Henschel from React 3.0 Fiber always showcases some interesting demos because there he's doing lots of stuff with 3D rendering in the browser.

And there you have this, when you put a component, when you put like 3D stuff into a component, this one component can grow in size quite quickly in performance-relevant size. So this is, I think, a pretty good use case. And this is why he's a pretty big advocate for those features because there, you can really make use of them because you have a medium amount of kind of heavy components. And this is, I think, the situation where this shines the most.

Excellent. Thank you ever so much. Thank you from me and I'm sure on behalf of the audience who are going to give you a massive round of applause. Thank you for such an insightful talk. Thanks a lot for having me. Having a pleasure.