From Redux to Zustand to Jotai to Zustand to Custom: Our State Management Horror Story

Today, I want to tell you about how we did a bit of a horror story that we call it ourselves and about how we changed our state management infrastructure too many times. So let's get right into it.

What are we talking about? We're talking about this product here that I'm working on called Plux. And it's a very nice CAD, electrical CAD software for the web. Basically, you can design circuits, design electronics, the schematics, the PCB. It's like there is a lot going on and you can create connections and simulate circuits. It's cool.

And why are we talking about this here today? Well, because it's built on technologies that I guess that a lot of you know. It's a TypeScript application. We have like a half a million line of code of TypeScript and it's built with React, both the UI part and the 3D canvas part. It's built with Three.js and React 3.0 Fiber. So we are actually building on like a giant CAD tool on top of React 3.0 Fiber. And one question that I heard a few times from people that I talk to is, okay, React, but how are you handling state? Like are you using two standard Redux just hooks? What are you using? And my answer to that is in a meme way, yes. We're using a bunch of different libraries and we switched them quite a few times.

And why did we switch libraries too many times? Well, it was a bit of a discovery process. And this is because our product is quite challenging. We want to support enormous documents, which like 10,000 electronic parts, each one it's a 3D model with properties and stuff. And we want to support real-time interaction. So you can click and drag everything and the multiplayer, like what you do with the Figma and Google docs, you can just edit something and everyone else will see it. And we have a complex system of cascading rules, like every electronic component has dependencies between them. And we are running a bunch of computation in the background, like computing electrical properties, computing geometry, and that is all running in WebWorkers. And we have these kind of data pipeline because we are processing our data a lot before being able to show it to the users.

And there are weird dependencies between data and all of those challenges with the target of being able to run it at 60 frames per second on medium and hardware, which was incredibly difficult to do. So let's talk about the start. Where did we start with that management? Well, with Redux, of course, we love Redux. We still use it today. And the reason why we're using Redux is because it's our repository for persistent data. The entire document that comes from the server and then goes back to the server, it's persisted in Redux, which allows us to do something quite cool. We have automatic multiplayer and persistent and synchronization with the backend. Every time that we perform an action on Redux, everyone that everyone, every other person that is visiting that link will be able to receive it on their end. So that we don't have to take care of that, because every developer can just send the actions into Redux and it will automatically persisted and broadcasted. And we're doing that with the RxJS and Epix. But I don't want to get too much into that today because I want to tell you about the story of how we changed it.

And the reason why it's because at a certain point, we started developing a new editor, the PCB editor, which was much more complicated than the one that we had before. And we had the need for derived data, which means taking the data from the document and processing it. And normally, what you would do is that you would just do it in your rendering. But we needed this data all around the application. We needed to be able to access that data for interactions. For example, the position of a node, or we also needed to be able to export that data in different industry standard formats. So we couldn't do something as simple as getting the data from Redux and just render it as it is. But we needed to do something a tiny bit more complicated. We needed to process it and store it somewhere. And that somewhere was going to be used by a lot of different systems. Rendering, user interaction, export. And we were thinking, what should that something be? Like that looks like cache or a store. That's why we introduced GSDAN, which is this cool bear and the cooler brother of Redux. It's a state management library. I guess that other people heard about it. Which is quite easier to set up and maintain. Like it has a lot less boilerplate code. And the reason why we choose this, it's because we heard around that this was going to be faster than Redux. Maybe. We weren't really sure, but we had to start somewhere. So we started with this.

And to discuss performance, I will bring a classic example. In our application, we have a lot of different nodes, which are like the elements. And we want to, for example, render them in a list or render them in the canvas. How would you do that with React? Well, you start by creating a store, which is here, SUSAN Store. You create your renderer component for your node, which subscribes to the store with this new store hook. And then you loop over your entire state with a map and you render all your nodes. Simple enough. But you probably noticed that there is already a rookie mistake here. If we are doing that, then we are basically subscribing to the entire store because we're not using a selector there. So what happens? We change one node and everything renders, because a used store is basically a global subscription. And the solution for that is, of course, using a selector, which is this kind of lambda function that allows us to tell SUSAN which part of the store we are interested in. And selectors have been discussed a lot, like there is an entire long page in the Redux documentation about it. Which means that we can go even deeper. We maybe don't want to subscribe to an entire node, but even one single property of a node so that we can reduce the renders even further. So we replace this and we put everything inside the selector lambda function like this. And that's actually a pretty common thing that you will see in a lot of applications. And we took this a bit religiously in Flux. We had the goal to reduce the renders as much as possible. So let's create more complicated selectors. Let's create a selector that has loop inside of them. And once we reached this, we were thinking, are we selecting a bit too much? We are trying to reduce the renders so much that our selector became the problem once again? Well, the reason why we did that is that we started with this assumption, which is what everyone talks about. The reactor renders are expensive. You want to avoid reactor renders. So you do whatever it takes to reduce them. But what we were wondering is, what about this? What about this selector part itself? Because every time you use a selector, those selectors have to be run. When you do a set state on Zoostand, all the selectors are called. And all the selectors that are evaluated then need to be compared with the previous value. So you are almost rendering everything. Just that you are filtering at the last stage. And we were wondering, can this become a problem? Well, we have documents with 2,000 nodes.

Each node has like 20 store hooks, which means a lot of subscription. And then we introduced also that some selectors became O-N of complexity. User interaction now takes 10 seconds. Congratulations, your software is slow. And so we realized that, yeah, maybe we have to change something. It can't be that you press a button and you have to wait 10 seconds.

And in fact, we look at the profile, and we're like, set state, listener. That's all selector evaluation. What is happening here? Why is asset state taking eight seconds? That's because selectors sometimes can get expensive when you have like 200,000 of them. And which, I know, it's an edge case. But basically, my job is constantly going around edge cases. So we asked ourselves, OK, so using those kind of hooks with selectors is basically still a global subscription. What if we could do granular subscription? What if we could subscribe to only one part of the store without using selectors, maybe by just firing the correct one straightaway?

Well, what we discovered is that the reason why state management library uses selectors so much is because if you use them, your state management library does not need to know what you did in your set state. Let me give an example. Let's implement a tiny do stand in which we have our state, our global listeners, and our set state function. In our set state function, we just call the state transition, the reducer. And then we call all the listeners. Let's suppose we want to be a bit more smart and just call the listeners that care about what changed. How would we know what happened in the state transition function? We have no idea about what part of the state changed. We will need to perform a giant diff, which is not feasible. So it basically became clear that Zustand was not the right model for us. It's a great model for auto web apps, but maybe not for us. So it's time to replace Zustand. Yay! First refactor. And we looked into some alternatives, and one alternative that seemed very, very promising was Jotite, which is another very cool state management library. How it works is that it's very similar to Recoil. Probably you already heard of this. There is this concept of multiple different atoms of state instead of a single one. And it allows you to model computed data as derived atoms, basically a subscription or a subscription, which allows you to model data in a bit of a different way. And the way that we managed to sell this to management and convince them that we needed a refactor was that this was a shiny new library that was a, hey, maybe this thing that is proven by the industry could solve our problems.

And that was a great trojan horse to just do a bit of performance work. So what we did is that we took this model with Zustand that called all the subscribers all the time, and instead we transitioned to atoms in which now we're finally able to just call the processing on that specific atom and be much more precise with a subscription. And to prove that this was the case, we just did a tiny sandbox, like a different repository started from scratch. And it seemed very promising, like an approach with Redux to one second for interaction, whereas an approach with Jyoti took like only 70 milliseconds, which was much, much faster. So this was definitely a success. Let's implement it. And we went and we did this giant refactor to adopt Jyoti instead of Zustand.

But then we realized we still had to keep Redux around because otherwise it would be too much of a rewrite. So we still have that to factor in. And then we realized, well, every node is not independent. We can have a node that is child of another node so that you have to update together. So we would have to write a piece of code that is able to keep track of every dependency. So no, that would have not been possible. And then we realized that some things that are actually simple, like getting the current value like transiently, or getting the value of all the nodes at the same time became too complicated. So what it turns out that we had to work around the Jyoti limitations. And after the migration, it was worse than Zustand, which was fun. So what happened is that we reverted it. But actually, no, we reverted only the Jyoti changes because, you know, when we did this giant migration, we were forced to do refactors around to adapt to this new data model. And these refactors that we did was actually extremely useful. So we managed to sell better performance with new state management library that didn't exist. And we got a nice refactor in the process which helped us immensely in the future.

How? Somebody asked inside the company a weird question, well, you know, like if a single thread that process all the data is low, what if you split the data into multiple threads and process it independently? Well, not really. But the question was, what if we split the Zustand store? Like if one store has to fire all the subscription, what if we split the store into smaller Zustand stores so that each one has its own subset of nodes and has to call less subscriptions? Well, it turns out that someone else talked about this already. And in fact, then Abramov said that it's a bad idea, unless you have performance problems. Like if you have thousands of items that are on screen at the same time, that's us. So that's exactly what we did. Let's look at how it works. First of all, we did a hash function, which, given a node, gives you what is the partition. So then we can map in a constant way, always the node to the partition. Then we create one Zustand store for each one of those partitions.

And then when you want to use it in React, you have to get the store for that specific node and subscribe to it. That might seem weird or a bit overcomplicated, but the results were there. An interaction that before took eight seconds. Now it took 38 milliseconds, so like a 200x improvement, which was really nice. And so we thought, basically, instead of having your performance depending on the number of the nodes, now it's the number of the nodes divided by the number of partitions. What if we made p equals n? Are we going to have 0,1? What if we make one partition per node? So we talked about this with a few people and a consultant. Which said that basically, right now, unfortunately, there is no open source library that does that because we are not 99% of what apps nowadays. But we are doing something that a bit pushes the limits of the web platform. So maybe we need a new way of thinking about the problem. And this was our excuse to sell another refactor. So what did we do? We created our own store. We decided to go fully custom, which actually was really simple. It was like a bit of an abridged version of what we're using. Actually, it's a bit more complicated, but you get the gist of it. It is that we have a store which keeps track of all nodes and for each node, who is subscribing to the node with a Wikmap. And when we do the set state, we don't do a set state on the entire state, but only on a single element so that we are able to call precisely what is the subscriber that is interested in that change. And we couldn't do that before the Jotai refactor because we didn't have that information. And now we finally have it. We change all our system to support this. And we can still have a global story instance or inject it with a context like you would do with Toast or Redux. And when you want to use it with React, basically what you do is that you subscribe and then on the change, you set state. Or there is a very cool API that React has had for a while, but I don't know if anyone knows about it, which is a useSyncExternalStore, which is a specific hook to which you can pass the subscribe function and the function to get a snapshot. And pretty much that's it. You can basically implement a bridge between React and the state management library that way. The results were amazing because on top of the 200x improvement that we had before, now we had another 200x improvement. And so finally, we did the thing that we swore that we would never do, that is the custom solution, and actually works great for us. So does this mean that Zustan, Jotai, Redux are bad? No, they are amazing for what they do. They're amazing because they are fast and they have some performance imitation, of course, but those performance imitation are exactly what allows you to develop faster. Imagine if everyone had to accurately model their data and then build a custom solution on top of it, that wouldn't be feasible. But existing libraries, they have an obstruction.

They may be force an obstruction of you. And sometimes the obstruction can work, but sometimes it cannot. And I think it's very important to figure out when that is the case. When you figure out that that obstruction doesn't work for you, because I think it's very easy to just get blinded by the, oh, we cannot do it differently and just build on top of stuff that will not work for you.

And the last thing is that maybe don't lock into the solution. But even if you do, it doesn't matter because migration and custom solution are possible. Like we did it even though we were thinking that it wouldn't be too much of a ride. And it was, but it was immensely good for our performance. And sometimes you even make friends along the way. Sometimes you do migration, it fails and you're left with a greater factor and a great learning that helps you in the future. So, thank you.

The first question is what was the timeline for this whole set of changes from going to Redux all the way through to custom solutions? One year and a half, I think. How long between each of those steps, though? Basically, the moment that we finished one, we immediately recognized that we needed something different. That feels like the story of my life. And also like slightly chaotic, I imagine that must... How did this work interact with day to day work in other areas? I mean, that's an interesting question because a lot of people use that data. And so you have to a bit manage the fact that you had pending PRs that were about to be merging, to be merged using the old API. So you have to a bit freeze everything. But thankfully, the colleague that did those refactors basically changed the code for them, which was incredibly nice. So sometimes you just have some angels in your company that do the things really well. Enabling you to move from state management to state management tool. All right, so next question here is when do you plan to open source it? We need more than one state management library. I mean, we could absolutely open source it. Just at the end, our solution, it's very tailored to what we're doing. And I think that it will be a bit of a like, if we open source it, it will be like either we post it as a gist to somewhere, hey, here is how you could implement it as an example. But I think that if you actually want to open source something and you have to maintain it, and it doesn't make sense if then we are not going to adopt it in the first place because we are too scared of then having to be bound to something that we can't change in the future. Yeah, I completely agree for what it's worth. Open sourcing code that comes with a whole set of expectations that you need to meet. But if everyone is interested to know how it works internally, just ask me. Probably I can show something.

Nice. All right. Next question, which is kind of funny in context of your talk. Is state management actually necessary? Isn't the best state management is use state and use reducer, isn't it? Yes. I'm glad we got that one out of the way. Thank you, everyone.

Okay. So next question. And these are going in terms of the most thumbs up questions. So if you're interested in seeing specific ones, that's your prompt to get on Slido and do that. What about MobX? Was that a consideration? I have to admit it. I never looked into it. I'm very sorry. I mean, that's a legit answer as any, to be completely frank.

How did you find the tools which you ended up moving between? Like, how did they first, if you didn't really look into MobX, I'm kind of curious, how did the others kind of come into your orbit in the first place? Who? You mean how we found Jotai and? Yeah. Well, because basically what we did is that, I mean, we were a bit gravitating around that set of libraries, which is like done by that open source team that also did React ReFiber. But also like we realized that eventually we had to do a custom solution. So we looked a bit around, but not too much because like we're trying something and probably we're going from one library to the next before doing like an accurate selection. No, that makes sense.

All right. So kind of a similar question that might end up having a kind of similar answer. I think for most websites use context is enough. Why should we use something like Redux? Well, I actually absolutely agree with that because I think that Redux and just on the libraries like that to help you because they allow you to have some sort of very isolated piece of code that handles your state and you can isolate that code very well. And the other thing is that with use context is a lot more complicated to work with it if you have systems that are independent of it. Like if you have a web worker that is running in parallel and that is supposed to put the results of something into a state. I think that's a bit easier to do it with the Zustan than to just use a use context. So it's a bit of an ejecting from React thing. Yeah.

OK, next question. What do you think of creating a package for your custom state management, selling it and then creating another one to replace it? I saw that pattern happening a few times.

I feel like that's the sequel to this talk. That's next year's talk, right? Have you considered using signals in your work? Not really, but that could be an idea actually, because I think that it's similar to what we're doing, actually. Yeah.

OK, wow. There are a lot of questions and not a lot of time. So just a reminder before I ask maybe the last one or two questions that after this session, if you're here in the space and there's a speaker Q&A space round by the entrance and that's where you can ask further questions.

How do you how do you recognize the performance issues? How do you, how did you recognize that the performance issues were because of state management libraries? Yeah, like it was a bit of a debate also inside the company because people saying, well, I don't think that that's the case. And people were saying that, yeah, that's the case. And at the end, it's a lot of profiling. It's looking at what is happening inside the like when you profile an interaction and see what is the set of function that is being called. And because sometimes it's like it's very clear in the moment that you are seeing that you do an action and most of your time is spent during the listener stage. And then you see that all of the selectors are being run after one after each other. And it's one takes a tiny bit of your profiling time. That's the way that we found out, basically, just through profiling. Yeah. And a bit of detective work as well. Yeah, exactly. The detective work is, you do a factor and then see if it actually improved or not. And find out if we were right. Awesome.

Well, that's all the time we have for questions. Don't head anywhere. I have something very important for this group. So don't don't do a runner quite yet. But before we wrap up, can we give a huge round of applause to Giulia for a fantastic talk. Thank you ever so much. If you head off to Friday the 6th.