Using Redux in Modern React Apps with Mark Erikson

XState for State Management in React Apps with David Khourshid

State Management in React with Chance Strickland

Using Recoil to Manage Orthogonal State in React Apps with David McCabe

State Management in React with Christopher Chedeau

State Management in React with Paul Henschel

Managing Complex State in React with Jared Palmer [explicit]

Using react-query to Manage Server Data and Cache with Tanner Linsley

React State Management in 2021

Paul Henschel is a frontend developer based in Germany and Switzerland. The founder of Luxundlaune, a photography platform in Germany, Paranoidandroid, a custom firmware for Android, and several open-source projects like [react-spring](https://www.react-spring.io) and [react-three-fiber](https://github.com/pmndrs/react-three-fiber).

In this interview, Joel and Paul discuss the biggest challenges in state management, picking a state management library for your project, and the Redux mindset that everything should revolve around State. 

> Applications made without state in mind will turn into a mess, like a drawing. It doesn't scale. You shift into modeling stuff around refactoring. It's not great. If I write something big, I always start with a good stable state model.

https://app.egghead.io/api/v1/lessons/react-state-management-in-react-with-paul-henschel/subtitles

Joe: [0:01] That's exciting. The react-spring changed, is this a company that you all got going?

Paul Henschel: [0:07] Yeah, I'm not sure if it's a company. It's like a collective ecosystem.

Joe: [0:09] Collective. That makes sense.

Paul: [0:12] Several people working on libraries, and stuff like that.

Joe: [0:18] I pay attention to it because react-spring is interesting. More interesting to me than react-spring is it's like an ecosystem around there. I have noticed this tendency to take concerns, where people might stuff them into react-spring and create a library that does all these things.

[0:40] Instead, you seem to lean towards this notion of more modular purpose built tools that they can come and go, and are useful beyond the scope of react-spring. I was wondering where does that idea come into play? How does your UI development philosophy lead to creating that kind of ecosystem of libraries?

Paul: [1:09] Exactly. That's the idea behind us, to make things more modular, focused on maybe one thing or two. Basically, Unix philosophy. Not messing around, not mixing too much. Little by little, all these libraries, they started to come up. They were all grown from a little problem that maybe I or someone else had once. Then, it started.

Joe: [1:40] I've been doing this. I've been talking to different people. State management is this thing that pops up. React state management is something people talk about a lot, but that's, I think, because of the popularity of React in the general area of Web development.

[1:55] State management isn't a new problem when it comes to programming in computers. I was wondering, why is state management such an issue, or why does it get so much conversation when we're talking about building our applications?

Paul: [2:11] I guess, there's so many ways you can go about it, and none of these ways is the one defined way. You can have completely Magics on some BlackBox. I guess, that's called proxy state or whatever. You mutate things or you don't. There's streaming. This also has lots to do with the requirements that you have in your applications.

[2:41] When I started with Zustand, none of the libraries that I tried at least fulfilled my requirements, but I liked Redux the most.

[2:51] I liked the principles, the philosophy. I liked that it's immutable, very clear. It's functional. I always have been using Redux over something like MobX and stuff like that because I didn't like mutation or anything that's inexplicable, that's Magic. I didn't like it.

[3:17] Redux also had shortcomings. I also didn't like the boilerplate. All the ceremony, the opinions. Have you seen the Redux website, that's not like Bible or Zen of Redux, or something on it? It's pages and pages and pages. It's like a full book. That's just not my thing.

[3:44] At this point. I decided I go forward and create something new. I know that state managers are like a dime in a dozen. There's a new one coming out every day.

Joe: [3:56] I think your collective has just released another state manager. [laughs] You'll have two listed in there.

Paul: [4:04] We have two in Zustand.

Joe: [4:08] Why is that? What shortcomings of Zustand produced the new library? Is that somebody's opinion, or is that a preference, or an aesthetic that somebody's going for? I think state management is fundamentally difficult. That's why we see these. That's why our brains want to process it differently.

[4:29] What leads to that? Is it a competition thing, or is it just solving different problems for different people?

Paul: [4:35] No. None of these libraries are really. I don't care so much about competing. It's just problem solving. I've always used Redux for all the projects I start from scratch. I got into React Reconciler custom renderer, this kind of stuff. None of these libraries work because that's a technical problem in React. It has something to do with context.

[5:04] You have context object. Redux is based on this one, but it can't be shared between two renderers. The other renderer, like in my case, is a 3D thing, could not access the upstate. I thought that's quite bad. I tried to find ways around that. Nothing really worked.

[5:29] Then I started to look closer at what Redux really is, also the original Redux. It doesn't have a provider, the original, the one that just says Redux. You call a create function, and it just gives you the store back.

[5:45] I thought, "Hey, now we have hooks. Why can we not have the same philosophy, going back to the roots of Redux?" This is what Zustand does. You have a create function that gives you a hook. There's no provider. There's no context. You're not even getting into all these complex technical depths situations.

[6:07] Also of course, all the ceremony, I didn't like it. Redux, for instance, says "You cannot put function in here. Your action are special. You need action types," and whatever.

[6:22] I didn't like this. I wanted my site to be whatever I want, whatever the application requires. There's no opinions, no structure. You can put anything, even if it's not serializable, whatever.

[6:34] I liked this approach more. It can be 100 percent Redux compatible, but doesn't have to be. I guess, most people would use it as a context replacement, something like this.

Joe: [6:50] Is that react-three-fiber? Is that where this need arose?

Paul: [6:55] Yeah.

Joe: [6:56] There's actually two reconcilers, or multiple reconcilers going at the same time?

Paul: [7:02] Yes.

Joe: [7:02] Your problem was, these need to talk to each other, almost like they're components at that point. If the whole application is a component, you end up with two components. They need to talk.

[7:12] The core fundamentals of React and Redux and everything that's been built so far didn't work, so you literally had to create something new to solve a specific problem. It's generally useful as well.

Paul: [7:27] Yeah. That was money to me, because that was the initial problem when I just tripped over, but when I started to investigate, there was so much more happening that I didn't even know at the time that I needed.

[7:41] For instance, if you're having anything to do with 3-D games, that kind of stuff, you have the game loops, so it needs to be very fast. You cannot go through the traditional React approach, like refreshing props.

[7:55] Imagine you want to animate something going from A to B, or whatever. It doesn't make sense to involve React 60 times per second, every frame the object moves through from here to there.

[8:10] All these things we resolved more or less in Zustand, because you can notify a component of changes without re-rendering it. These patterns developed because we needed them. Redux at the time just couldn't put them on.

Joe: [8:29] The other internal library that I've seen that sounds like it solves a similar problem would be Recoil. Is that fair to say that there's some similarity in terms of the solutions there?

Paul: [8:42] I'm not sure if it's context-based, at least, we would still not be able to use it. I guess, it's context-based. I'm not saying it's something bad. It's just in my case, I saw no need for it. Recoil, I'm looking over the API. I'm trying to like it, because many people tell me it's super great.

[9:04] It has the export index, it's like 30 APIs, something like this. 30. It has a bigger API surface than React. I don't know. I don't have the time to study this kind of stuff, even if it's the best thing in the world.

[9:24] This was the reason we started with Joltik. This guy, Daichi from Japan, he managed to bring this atomic site model down to one API function. I don't want to be biased. I just don't know Recoil good enough.

Joe: [9:44] Recoil is built to solve a specific problem too. Whatever the scale is they're dealing with at Facebook, they're solving internal problems at Facebook, so they created a library that solved their problems.

Paul: [9:57] That's how it starts. Every library should have started from some problem, some issue, so it's totally all right.

Joe: [10:06] Do you think fundamentally it's an issue? Is there too much? Are there too many solutions? Do we have too much choice in the world when it comes to how we solve these problems?

Paul: [10:16] Yeah, maybe. Some people seem to be very affected by this stuff, like JS fatigue. I'm not fazed by any of this. I just like to think, progress. We shouldn't be stuck with one idea forever. I also would dislike if we had consonance that says, "OK, this is state," because it doesn't work.

[10:39] There's requirements and they change, and you need to adapt. Just look at how far we came along. All these paradigms, they change every couple or five years, or whatever. They're completely different, because our requirements are different.

[10:57] Like Recoil, is entirely new idea, I think. It's great. React is like a petri dish. Constantly things are evolving in it. I, at least, like this about React.

Joe: [11:15] Somebody was talking about how it was like styled system, or some other approach to CSS and JS, and they're like, "React should bake this in." I was like, "No." What I think is true and wonderful, and why React is as popular as it is, is because it allows for folks to hit problems and come up with user land solutions.

[11:35] Like the fact that we have 20 different state management libraries to choose from, it's a challenge. I don't know how many it is. It's probably more, right?

Paul: [11:44] 2,000.

Joe: [11:45] Yeah. It feels like this new one every time, but that choice, while it does frontload your application architecture, it's fantastic because we can come up with novel solutions and solve our problems. I've seen some of the stuff that people are doing with React Three Fiber and the VR libraries and the physics. It blows my mind that this is React at all.

[12:09] Like they were able to do that with this Web application library. It's amazing, frankly. If it had a bunch of opinions, it would crush that upfront. You'd be following their opinions and going about their approaches, versus coming up with novel design.

Paul: [12:29] It's a bit like React's competition, I think Vue, Angular. In some ways it may be great, because a beginner comes and they just have something served to them on a silver platter, but I often think it holds them back. That it's almost like a buffer.

[12:50] For a library to be established, it's hard. I started Zustand, for instance, one year ago, something like this, no one knew about this. It got no recognition. I don't even know what happened that now a thousand people use it, or whatever. Not so many. It's hard for something to establish, so that also serves as a safe buffer for beginners to figure stuff out.

[13:17] They hit, I don't know, "state management," in Google, for sure it doesn't come up. Like some nonsense, literal state manager that was generated yesterday, it doesn't work like this. There's Redux, there's Recoil,, there's MobX, that's it. There's Nu-Batch, but you need to dig a little bit deeper to find it. I think that's fine.

Joe: [13:41] I've heard it described as layers of state, too. At the core of it, React provides great tools, especially with hooks. Hooks changed the game. Context is great when that works, but what do you need when you break out of that? That's where something like Zustand comes in, right?

Paul: [14:00] Yeah, definitely. I don't like the context too much in terms of state management, but as a data distribution model, it's great.

Joe: [14:11] Yeah, that's a good way to phrase it. I like that. I've also heard that a lot of times when folks are thinking about state management what they actually want is a cache. Like loading remote data, whatever, you pull that in, you're not really managing state, you're storing data and sharing data, which is a factor of state, state is data driven, but at the same time, it's a different problem space.

Paul: [14:40] I saw this React KWin that does it a little bit. Like many new libraries coming out using the Suspense mechanism, it's a exciting space, data-fetching, caching all this stuff. You hear my dog in the background?

Joe: [14:58] Dogs are great.

Paul: [14:59] I think he needs to pee, but he needs to wait a little longer.

Joe: [15:02] One of the things that I think is interesting, and correct me if I'm wrong, is animation is largely a product of state, and the problems that you've explored with animation, to me, feel basically like a state management issue, especially when you're trying to automate and animate based on conditions, or in a UI.

Paul: [15:25] Yes, that's definitely true.

Joe: [15:26] Is that true?

Paul: [15:28] Mm-hmm. For me, this idea of hooks changed everything, because before I would model my application around the animation. That was, at least in my head, what makes it so complex. With hooks, you have your bare bones application and you have a flag that says, "On-off." If it's on, on is green, if it's off, it's red. You have everything you need.

[15:53] You just put a hook as an intermediary function, and that turns this static thing into something that moves. Yeah, it's state, state made movable. That was amazing to me to see it the first time.

Joe: [16:17] I'm wondering, when you sit down to architect a new application, what's your approach to even thinking about the states? A new application, do you consider the problems that will arise, or is it something that happens as you work, do you evolve your solution over time?

Paul: [16:38] I still have this Redux mindset. To me, at least, that is the most important part of the application, everything should revolve around state. The applications made without state in mind, it turns into mess, like drawing. It doesn't scale as well. Then you're shifting into your modeling stuff around refactor. It's not so great. If I write something big, I always start with good, stable state model.

[17:14] I need to know how it works, how it distributes, how it affects my component tree. To me, at least, it's important and most of these descriptions on the Redux page, they're all about this. Like, the Zen of Redux. It's not a dig against it, I like what they've done, it's just very deep, but they have a point.

Joe: [17:43] Redux, it hit, and has been just popular up to the point where everybody's like, "Stop using Redux," but then it's still seen a popularity. To me, what's cool about Redux is that Zen. Maybe you can take that too far. The philosophies underneath it, and the core principles over the implementation of the library itself, it's like, "What are we talking about?"

[18:12] To me, what was truly mind-blowing was the idea of the store, the single source of truth. Wait. Hold on. We can save all this up at the top. Everything can reference this. The entire application can be coordinated based on state. That kind of philosophy was my takeaway from Redux.

Paul: [18:34] I liked it so much in the beginning. I tried to avoid it because it looked very complex. At some point you couldn't because it was in everyone's ears and mouths. Everyone was talking about Redux, so I started learning it. Also, I learned JavaScript because of it. I had no idea about functional programming reducing.

[19:00] I'm glad I went through all this churn, and what people call boilerplate. I totally understand why they haven't liked this. It's not so necessary for some requirements. You can use the same principles and philosophies for something that is maybe a smaller scale. It doesn't have to be like actions, action types, dispatchers. It doesn't have to be like this but you can still adhere to the basic principles.

Joe: [19:31] Those are implementation details, right?

Paul: [19:35] Right.

Joe: [19:35] Because you've taken those same principles. Zustand represents them at the core fundamentally. It's inspired by and has a direct line that you can draw between the two. You've done it. It's like you say, the atomic state is interesting too, because it feels in certain ways like it's addressing some of the same principles too, but coming at it from a different implementation.

[20:02] Same idea. New implementation, different use cases perhaps, different ways to think about it, too. It's our mental model of how we approach a magic state in our applications. Do you use state machines?

Paul: [20:17] You mean like what does?

Joe: [20:21] XState in particular, would be the JavaScript.

Paul: [20:24] But, it's piano teacher?

Joe: [20:25] Yeah.

Paul: [20:27] I don't know. I found it very interesting, I suppose. It's always the same for me. I go to someone's GitHub. If I can't comprehend with one glance what it really is, I avoid it. That's why I didn't really try it at all. It looks to me a little bit like overarching, but I have no idea. Also, it's the same, like Recall. People tell me it's the best thing ever. Could be.

Joe: [21:00] Your brain doesn't have it. I know what you're saying. You look at a state machine.

Paul: [21:05] It's personal.

Joe: [21:06] It's this wall of very specific configuration.

Paul: [21:10] Exactly, the whole spectrum, I look at it. I'm not a very logical person. I don't function like this. I need it to be very intuitive and non-digital, if that makes any sense.

Joe: [21:27] I'm wondering. In this, is that the draw, the functional programming approach, too? You don't strike me as a purist in any form.

Paul: [21:40] No.

Joe: [21:40] You're open to new ideas as long as they're simple and allow you to work.

Paul: [21:44] I like obstructions and tools on thresholds. I don't like Magic. For me, that's just like a sweet spot between something that is a great something and does everything, and something that still allows you to be explicit about it.

[22:07] I would rather have a library that I use to be somewhere in the middle, like obstructed enough so that's it's real, but that's still explicit. For this I also take a couple of lines more if I have to write them just to be not implicit.

Joe: [22:30] Has anything come out of this, creating these libraries, that surprised you? Has anybody created anything where it gave you a wow moment?

Paul: [22:41] You mean what people do with this?

Joe: [22:42] Yeah. Somebody's taken what you made and created something that you wouldn't have expected beforehand.

Paul: [22:49] Yes, of course, because there's so many levels that have accumulated now. There's React green room, React use gesture and switched arms, React-Three-Fiber. I don't know, some others. There are so many. I follow people on Twitter that they ping me, show me their work. I enjoy this. For me, that's my reward. I don't need money, recognition. I don't care.

[23:18] [dog whines]

Paul: [23:20] My dog. [laughs] I like to see what people create with this stuff. Of course, I'd have anonymizing things like what you mentioned, VR, AR. The craziest thing is that all of these libraries work together. They're inter-meshing. Recently, I saw something that just blew my mind. Some guy makes maxi Minecraft game off the letters.

[23:48] Practically every library I created, there's the Zustand directory fiber, RevSpring, Funimation. It was crazy, like a soup of all these different things. Somehow, because of React and the Unix philosophy, it works. That's great.

Joe: [24:08] It all just connects together. Lots of the types. Love it. Paul, I really appreciate it. Thanks for chatting with me.

Paul: [24:17] Thanks a lot, Joe, for having me.

Joe: [24:18] Cheers.

State Management in React with Paul Henschel

Share this video with your friends

Course

React State Management in 2021