Context is like a dependency injection system. You put some value in at the top. It comes out at the bottom. It doesn't offer a way to update or store anything by itself.

You're listening to episode number 12 or 20 minute JavaScript where we discussed everything javaScript related. This episode much like all others, is hosted by open replay and open-source session replay suite for developers. Stop guessing your production issues and check out openreplay.com. I'm Fernando Doglio, your host and StackOverflow power user for the next 20 or so minutes. And today we're going to be talking about Redux and Redux toolkit, with a very special guest. Some people know him as"that Redux guy", others like his parents, know him by his name, Mark Erickson. He's one of the maintainers of Redux and the actual creator of Redux Toolkit so, mark, welcome. Thank you for being here. And for those who've been living under a rock, please introduce yourself..

Sure. Uh, I'm I'm Mark Erickson. Uh, as you said, most people probably know me as the Redux maintainer. In fact, there was a, there was a YouTube comments thread yesterday where someone was pointing out that I basically show up anytime the word Redux gets mentioned, uh, as far as my day job, uh, I actually recently switched jobs and I'm now working for a startup called replay. Where we're building a true time, traveling debugger for JavaScript applications. Uh, it's, it's a lot of fun to work on, and it is a really, really useful tool for understanding what's going on in your code.

Awesome. Interesting. All right. Uh, Today, we're going to be talking about, well, essentially Redux and Redux toolkit, but you know, let's put it this way. I want to hear it from the source. I've been reading a lot about state management lately, and I've been reading the opinion of many people, but I know you have a very strong one in regards of Redux and Redux toolkit, so I want to, I want to know what you think. Uh, but before we get to that, I want to intro into it. So, uh, can we start at this at the beginning. Can you. Guide us through how you see state for a react application. What is it?

Yeah, so I would say. State is it's it's data. It's it's what's going on inside your application. Um, like it's, it's literally the variables and the pieces of information that you're dealing with and we can, we can slice and dice and describe state in, in several different ways. One, one thing I've seen is there's, you know, for example, there's server state data that is like the source of truth is whatever is on the server right now. And we just kind of want to cash, fetch it and cash it on the client. And we want to try and keep the client and the server values in sync with each other, as you're using the app, uh, in the flip side of that would be like client only state. Which is data that is just inside the application as it's running inside the user's browser. So things like is the dropdown open, which item is currently selected. Um, And we could go into lots of other pieces like that. Uh, another, another kind of avenue that you could look at it is things like location, state, you know, when we're dealing with browsers, URLs are a very important piece of it. They, they help determine. Which piece of the UI we're looking at right now, we can pass values through query parameters. Um, so you can, you can divide, stay along kind of like several different axes or categories, but it's all different aspects of what data are we dealing with in the application right now and in the react ecosystem, especially we have this idea. Our UI is always based on the state in our application. And so we have a very strong emphasis on managing state as the way to actually manage the UI. In the end, if I want to show a modal, unlike the jQuery days, I don't do, you know,$.myModal.Show or something. I would do a set state and say mode like set is modal set, modal visible. True. And I update the data and then the UI gets updated in response. So like all applications have state, whether you consciously think about it or not, but we especially have a strong emphasis on that in the react ecosystem.

Uh, interesting. Okay. And. That translates into so many alternatives, so many different ways of dealing with this data, as you mentioned it, but out of the libraries and options that we have react itself already provides kind of simple ways of dealing with this and, uh, through props and through useState and through the use of context providers. Are these tools good enough for any type of state management scenario, let's put it that way or are they lacking features that bigger or more complex applications would need?

Somewhere in the middle? So it is absolutely possible to build very, very complicated apps with only the tools that react itself provides for, for managing state. So really what react provides is the ability to track state on a per component basis, whether it be the classical, this dot set state function in a class component, or the use state and use reducer hooks and a function component. But there they're all really equivalently the same thing. There's a piece of state associated with a component instance, somewhere in the tree. And in react, Data flows through the tree in a top-down manner. So you have parent components, passing data as props to children, which can pass data as prompts to their children. Alternately, you can stick values into a context provider to make it accessible to an entire subtree of the application without explicitly passing it through every value, but either way, the it's a very hierarchical. Top down data flow and that's intentional, but there are limitations to what is built into react. And that's not to say that this is bad. It's just that reacts tools are designed in a very specific way. And there are times we need to build applications that don't exactly fit that approach. There are, there are lots of times when we have data that doesn't neatly fit that hierarchical top down data structure. Like my, my UI is shaped like a tree, but maybe my data is not. This also gets into a discussion that I keep bringing up over time, which is what is my application? Is my application, my UI components? Or is my application my data layer? And you see people building apps with both of these different conceptual approaches and they're both valid. But they lead you in very different directions towards how you architect the app. Like if I'm, if I'm focusing on things where my UI is my components, then I might be doing things where I want to make sure that every component has like, is totally responsible for all the data that it needs by itself. So that, for example, maybe I could test that one component and it already handles all the data fetching and it just works or I can move it around the tree and it does its own thing. Whereas if I approach things from like my data layer is the app. Now I might want to approach things as testing that I can modify my data and my in my state changes whether or not there's a UI attached to it. At all. So I do see kind of like this conceptual split in how people approach, designing their applications. And they're both valid, but this goes back to the point that it, like, if I'm taking the latter approach, then I probably am more focused on managing my data outside of react, because I want to, I want to focus on building the data layer, the state management layer by itself, separate from whatever UI I might have.

React or otherwise. Yeah, I get it. Right. And that is where solutions like Redux or Redux toolkit come into play because they are not really dependent on react. Right. Okay, perfect. Understood. Uh, before we get started into a specific specifically naming some of these um, solutions, there are way too many solutions already. So, um, absolutely. Yeah, and I, I guess that's, that's a problem with, in general with JavaScript, we have way too many options, but in this space of, uh, state management, would you say that. The huge ecosystem of slightly different alternatives is a beneficial or is it actually like counterproductive because it's diluting the effect that some of these approaches may have by overwhelming the developers with so many options..

Again, also somewhere in the middle. Uh, it's great that we have a bunch of options and there are a bunch of very good options in the react ecosystem. The strength and weakness of the react ecosystem has always been that there's no one single defined way to do most things. And so react developers have always gone out and invented new libraries and push the boundaries and come up with useful new tools. The bad news is that now you've got to pick between 50 different options for the same thing. Um, so it, it is true. We both a strength in a weakness.

Yeah. All right. Let's find your ideal state management solution. I guess it might be. Exactly like Redux Toolkit, but I want to know if you managed to achieve that with RTK or, uh, are you still far away from the ideal set of features, the ideal logic behind it? How do you see the ideal state management solution?

I'm not sure if necessary to spend time thinking about what would be I deal per se. So let's, let's actually back up a bit like what is state management? And I do feel there, there is a lot of confusion over this term itself. Uh, so I think at one point I tried to define it. Like a state management tool is something that allows you to store a value. Update the value in the future and read the value or possibly get notified when the value changes. So, you know, the use state and use, reduce or hooks fulfill this because they let you read the current value by accessing the array. They let you call the setter or the dispatch function, update it. And you're notified it changes because the component is re rendering Redux fits this because it has a state of value inside. You can call it, get state, you dispatch an action, update it, and you can subscribe to know that an action was dispatched and calls get saved to see what a changed mob X fits this because you've got state in your, your observable classes and value. You can mutate the data to update it and mobX takes care of automatically applying the changes to whatever pieces of the code actually depend on that value. Uh, the piece of confusion that I repeatedly keep seeing, and I'm going to rant about this for just a couple seconds, is people keep saying that I'm managing state with context. And I'm nitpicking, but this really is a, a, a confusing point that people misunderstand context doesn't manage anything by itself. Context is like a dependency injection system. You put some value in at the top. It comes out at the bottom. It doesn't offer a way to update or store anything by itself. Your act like if you're dealing with state, you're actually managing it in a used state or use reducer and you just happened to be making it available via context, rather than passing it down by a props. I could have done the exact same thing by manually passing the data down as props all the way through. So part of the re one of the reasons why I think we have so many different state management tools in the react ecosystem is that there is no one single ideal way to manage everything. My, my favorite word as I've gotten deeper in my career is trade-offs nothing's perfect. Everything has pros and cons. Everything has trade-offs. So. Let's let's very briefly look at three common tools in the react ecosystem, so that all four, so react components, state it's built in. You don't need any additional libraries, but it is limited to the component tree. And by default, like you update state in the component, everything below that is going to start re rendering, uh, Redux it's outside the UI. It has the cool things like the dev tools and middleware. It does require work to set up a, it does require extra discipline and writing more code than it would have had in just the react component. Uh, but you get extra benefits, like being able to do to inspect the history of the state. Um, it also requires that you think in functional programming type terms, mob X is relatively simple to use. Conceptually, you create some classes or some plain objects, mark them as observable. You just mutate the fields and mob X takes care of passing along all the updates automatically. Um, It does kind of go against some of reacts conceptual principles as far as like immutability versus mutation, but in a lot of ways, it's also easier to use. Um, X state wants you to focus on defining data flows as explicit state machines, where you say here's the possible conditions that my system can be in. When a certain thing happens, it transitions from one state to another. And that allows you to do cool things like visualizing how the logic in your app fits together. So each of these tools has different trade-offs different purposes, different use cases. You can use them for a lot of the same things. But a lot of it depends on what specific problems you're trying to solve. And also just like what your preferences are. If I prefer a more functional programming oriented style, I might prefer Redux over mobX. If I prefer, you know, dealing with classes and mutation that I just kind of want stuff to happen automatically. I might go with mobX.

Okay, so there is no ideal, no ideal solution. It's all preference. All right. So going into Redux now, I actually, yesterday I think I watch, uh, uh, um, a discussion you had with, uh, with someone, uh, on YouTube. And you were saying that. You're showing numbers in you, you're showing how, um, although people say that, uh, Redux uh, is dead or is dying, uh, it's actually quite the opposite. You show, you show charts and so on, and we're going to cover that in a bit, but, uh, other than the fact that that may or may not be happening, why do you think Redux has gotten so much such a big rep. Let's put it that way. Um, lately, is it because as you put it, you just put it, I mean, it covers all the, you know, it ticks all the boxes when it comes to what state management solution should be doing. So what is your take on that?

Like, like why have people gotten angry at Redux for years? It's been way. Th there's a lot of historical context that goes into this. So Redux came out in 2015 at the tail end of the year long period that I referred to as the flux wars, Facebook announced the concept of a flux architecture in 2014. And over the next year, dozens of different flux libraries came out in the ecosystem. And at first Redux was just another one of those flux libraries. And then it got really popular and killed off all the others. But that led to a scenario where people began to assume that if you were using react, you had to use Redux. And frankly, people began shoving Redux into a lot of apps that it never needed it in the first place. And that all that meant. You know, people began experiencing pain and suffering because they were using it in a way. It really wasn't intended to at all. And from there, you all, like you had people using Redux without understanding what purpose it was intended to solve in the first place. On top of that, the original Redux patterns shown in our docs for years were frankly, very verbose you've. You've heard the word boiler plate. Turn around a lot. And it was very justified. Like you had to write action type Constance and action creator functions, and lots of spreads and array maps, and concats and reducers for mutable updates and all this code, just to update a couple of fields in your, in your, in your state. And there's very good reasons for that. Like all these patterns had reasons to exist, but frankly, a lot of it was very painful to write. And it was very easy to make mistakes. And then you started to see overlap with tools that came out in the react ecosystem that overlapped with the way and the reasons people were using Redux. So early on reacts all contexts API did not work very well. And so people would use Redux just to avoid prop-drilling. Well, the new context API that came out in re react, 16.3 was specifically designed to solve that problem. So if the only reason you were using Redux was to avoid prop drilling well context already does that and it's simpler to use. People have always used redux to store hashed server state you know, data fetching your to do's and your users and in your comments and whatever else, you can totally do that. But out originally out of the box, Redux didn't provide anything for it. So you had to write all the code to do that yourself thunks and reducers and actions, and, you know, use effects and whatever. Data fetching and caching libraries like Apollo and react query were specifically designed to solve that use case. So again, like if the only thing that you were using Redux for was data fetching and cashing will, these tools are simpler in these reviews. So when we started to see the backlash against Redux in 2017 and 18, it was, it was fairly deserved. Like the shininess had worn off. People had started to see the pain points of using this tool. But especially when it was used in places where it didn't need to be used in the first place and new tools existed that solved some of the same use cases with less code.

All right. It's a matter of misusing it or using it rather for the wrong intentions. Oh. But they were using it for their own purposes, but it's not like there was anything better at the time. I guess. That's why. Right. So it will just be a matter of developers updating and stop using Redux. If it's an, if it wasn't meant for. If there was a better alternative for that particular use case. So let's, let's get too into Redux toolkit now. Uh, where does it fit here? I mean, after all D did you create it because of the backlash, because of the, uh, the highlights that the developers have done so far and then saying, well, we don't like these, or, you know, we're, we're not happy with these, so we're creating new libraries for it. Is that the reason why. Uh, the toolkit exists? Mark Erikson: Pretty much. Pretty much. Yeah. If you go, as far back as 2017, I had filed an issue saying like, we see people struggling with using Redux in these ways. How can we make the experience of using Redux better for people? And there was a very, very long discussion thread, uh, issue 2295. I remember. Right. Wow. Where we, we tossed around a whole bunch of different ideas. That issue didn't actually result in anything happening right away. But maybe about a year later, I had time and we started actually actively playing around with some ideas. Um, so like, I think the, the way the Readme describes it is Redux toolkit was designed to solve a few common complaints about Redux. It's too hard to set up a Redux store. There's too much boiler plate for common tasks, like writing reducers or making immutable updates. And I have to install a bunch of dependencies into every project. Like why should I have to manually specify like the thunk middleware or re-select or other stuff like that. So from day one, Redux toolkit has been designed to look like we looked at the things that redux developers were doing in their apps every day, the pain points, they were experiencing the kinds of solutions they were coming up themselves to solve those problems. And we tried to take the best of those ideas, put them in one package and make it the official way to use Redux so that it's easier to get started. It's easier to learn how to use it, and there's a lot less code to write. All right, but why a different path, a different library why not just implement all those things directly into Redux, is there still a use case value use case for the old way? Let's put it that way of using Redux? Mark Erikson: From No. And in fact, uh, I actually just a couple of days ago, published Redux core 4.2.0. And the only change in that@deprecated attribute on the original create store function. This does not change any of the run-time behavior, but it does mean that when you import that function into your code, you see a visual strike through. And if you hover over it, because you're curious, why is this thing stru strucked through the documentation description now says, please don't use this. Please use config configure store from Redux toolkit instead. Um, what we've seen over the last few years is that Redux toolkit succeeded. It solved the problems we designed it to solve. We routinely get people telling us how much, like they used to hate using Redux. And they started using Redux toolkit and they love it. Or like they're a brand new dev who just started learning Redux a few months ago. They jumped straight into Redux toolkit and they found it easy to learn and use. And that's, that's great. That's that's the problem we wanted to solve. And like, we, we completely rewrote our, our docs and our tutorials couple of years ago to show Redux toolkit as the standard way to write Redux code today. But unfortunately there's tons of material out there from other people that has never been updated. There's, you know, old posts on medium and dev dot to. There's YouTube videos. There's unfortunately Udemy courses that say that they're updated for 2022, but no, no. They're still showing patterns from 2016. And so there's people who are still learning Redux the old way. They don't read our docs. Then they will never know that Redux toolkit exists. And so this was my attempt to give them a less than subtle nudge and basically using the only means of communication I have. So. If I could wave a magic wand and replace every handwritten line of Redux code, every object spread every, you know, const add to do equals quote, add to do every, like all that stuff with Redux toolkit, I would do it in a heartbeat. Unfortunately, this is the real world and it doesn't work that way, but we want every person using Redux today to be using Redux toolkit, because it is simpler. It will save you a lot of code and it will avoid a lot of common bugs. Now you were asking like, why didn't we just shove this into the original Redux package? So we've, we've had a bunch of discussions about this over the years. The Redux core package in many ways was done after like the beginning of 2016. Like, if you look at the actual changes in the versions, we've put out like some very, very minor tweaks to things like error messages and TypeScript types. The actual behavior in the API was done years ago. And as we found out, including over just the last few weeks, there are a number of people who are using the Redux core who do not want anything else on top of it. They don't want any extra helpers. They feel anything else is too heavy. And, uh, when I, when I announced I was going to make that deprecation change. I got a lot of people who were giving me a very angry comments, on Github. So on the one hand, I still think they should use Redux toolkit.. On the other hand, I'm not going to like do things that would actively break their code or like force them to pull in more code than they would have to. There are a couple of technical concerns as well. So Redux toolkit uses the Immer library inside for simpler immutable updates. Due to backwards compatibility constraints. Right now, we actually have to call a, an Immer function that makes it work okay with older JavaScript environments that don't have proxies, which technically means as soon as you import anything from the Redux toolkit package, you are getting immersed code added to your bundle. Now in practice, we expect everyone using Redux toolkit would have been using those APIs anyway. So it's not like there's anything extra. That technically would have been a little bit extra if you were, if we shoved it into the Redux core package. And so we're, we're sensitive to those concerns. That's fair. All right. You heard it if you're starting from scratch. Forget about Redux go toolkit. Okay. Now Redux and the took it. They have a very specific pattern, as you mentioned, and the APA has been similar or. Slowly changing by that, but has not seen that many modifications to the way you deal with this data or, you know, how you send messages or updates or whatever. Lately or not so lately a few other alternatives have come up with a completely different approach. And that is the Atom based approach from libraries like Recoil and Zustand on code, watching videos and seeing code and testing it yourself. You see a very straightforward method of dealing with state. Would you say that this approach is. Missing something or is it just as valid or as scalable as dealing with or using the toolkit?

So my first caveat is I have not had a chance to actually try any of these other libraries, myself. Like I have far too many Redux related things that I don't have time to get to anyway, much less. Try out anything else in my classroom at this point. Um, it does kind of go back to my, my favorite word earlier. Trade-offs. You know, so, you know, these, these Atoms or these like multiple miniature stores in a lot of ways, they are probably simpler to use. You don't have to think about the men like the, the work of defining reducers. You don't have to think about defining actions. Dispatching them, um, like you, you've got like these little self-contained pieces of state, it may actually, in some ways be a little simpler to reuse that in a couple of different places across the app. Um, yeah, I'm, I'm definitely at the limits of, of what I actually know about the, the API APIs and how these things can be used. Um, the, some of the trade-offs are that. Maybe the process of where and how you update the data now gets kind of scattered through your different components. And so if you're trying to track down, like where does the data actually get used and updated? You might have to do more searching. Through the rest of the code base to like follow the imports, see where it gets it's referenced and used. Um, that's, that's not necessarily a bad, bad thing. Uh, it's just an observation that, you know, whereas with Redux, you, you know, to always look at the reducers, maybe with like a Jotai or recoil, you're now having to kind of like look at a bunch of different components. Differences in approach, not something that's inherently better or worse per se.

All right. Fair enough. Okay. Now, final question. Let's address the geen elephant in the room. Redux isn't dead, or at least the toolkit isn't that he's not even dying. So how would you justify going with the toolkit. Let's forget about the old Redux. Let's just talk about the toolkit. How will you justify going to a, for the toolkit approach? If there are other, I don't want to say simpler, but, uh, seemingly more straightforward ways of dealing with state and always, always dealing, uh, or seeing, looking at it from the POV of a brand new project. Getting started on a project and deciding on a, on a, on a state management solution, not something that maybe it's been using Redux for like 10 years, not 10 years, but you know, if you got the point.

That would be impressive. Yeah. Um, so there there's, there's a few different arguments you could make. Um, one is simply the, the appeal to popularity. Redux is still by far the most popular state management tool, like separate from react itself for react apps. Uh, my, my estimates are that it's used by around 45 to 50%, uh, react apps. The pattern itself is well-known that we have very good documentation. There's a very good chance. You will run across an app that uses it at some point in your career. It is a very known quantity. It has a strengths and weaknesses, but it is a known thing. Like it's not like it's, you know, it's well maintained and supported. So one thing is that we it's the semi default option. And frankly, that is why some people pick it as far as technical merits. A lot, like a lot of the original arguments are still entirely valid. Like Redux was designed to make it easier to understand when, where, why and how your data is changing in your application and the ability to look at the action history log and see the sequence of updates that occurred, like even just reading the names of the actions that were dispatched can help to tell you this sequence of events occurred, the ability to look at the state at any point in time, the changes to the state after given action was dispatched. The dev tools have the ability to show you the stack trace of where the action was dispatched in the first place. These are valuable tools to understand how the app is actually behaving the technical architecture of being able to plug in middleware of your choice into the store. And. Choose your own approach for async logic for being able to do things like centralized logging or analytics, or, you know, other customer behavior is still a very powerful model that, you know, you, you don't get out of the box, like react state, um, with Redux toolkit specifically. We have solved all the problems of boiler plate and everything else, and the amount of code it takes to set up a store, write a reducer make some updates, dispatch, and action is really pretty minimal at this point. I mean, it's, it is still absolutely more lines of code than like a single use state in a component. Even compared to other solutions, it's not like it's actually that, you know, w like way more lines of code anymore. And Redux toolkit does have a lot of very powerful utilities built in for doing things like managing normalized state, um, you know, to, to update things in a lookup table. We also, last year we added a new capability to Redux tool kit called RTK query, which is a complete server state data fetching and caching solution. So you define a set of end points, whether they be rest or graph QL or just a generic async function, and you can describe the relations between them. So like when I, when I update this piece of data on the server, we should re fetch these items and it automatically generates a reducer and a middleware that manage all the caching and the lifetime process. And from there, it gives you a set of auto-generated react hooks. So you can just call, you know, use, get Pokemon query Pikachu and your component. And it does all the data fetching and the S the loading state and everything else out of the box. So like, even that, like, you can, you can actually use it without technically without defining a full Redux store by hand. There's a way to I just kinda like auto magically make one for you, but that makes using Redux for even kind of like per component data, fetching a very valid thing. Like why, why should I have to write a use state and the use effect and a fetch function when I can just get a, get a hook that does. So there are a bunch of valid technical reasons to argue in favor of using Redux toolkit today. At the same time, it's not the best choice for every application. There is there's bundle size, there's mental concepts, there's, you know, conceptual overhead, and it is entirely valid to choose a different tool because of the problem space that you're solving or the preferences of how your team wants to work with things. And that's all I really want. I want people to look at the problems they need to solve, discuss the trade-offs and the pros and cons of the tools in the space and pick a tool that best solves the constraints that your team is dealing with. Fernando Doglio: That's fair. So there's definitely a lot of space and for it. And, and what you're saying is essentially it's a very mature solution that, yeah, it's hard to, hard to compete with. Awesome now. So let's go quickly to the last three questions. We ask every one of our guests, not related to Redux, but to the IT industry in your experience in general. So what's the best advice you ever received in some ways I'd have to think about that a little bit, but I'm just going to pick a phrase off the top of my head. Right. Um, I had a very good mentor during the first couple of years of my career, and it's not necessarily advice per se, but like the first thing that pops into my mind is he would say. We can make it do anything. It's just software. Um, like being a programmer is great. We get to build stuff from scratch. Like this thing did not exist. And now it does. And you know, you could, you could sort of take this as advice and apply it to a lot of different areas. Like we can make this program, do whatever it needs to do. It may take a lot of time. It may be really hard. Like it's, it's just code. We can think about it. We can build the thing, like it's possible.

Absolutely. As long as you have enough resources and time, that's that, that's what I, I like to say about, yeah. I absolutely agree with that. Um, what's it most excited project you to worked for?

So outside of Redux stuff, uh, at my date and my previous day job, I've spent a lot of time. Most of my career, really working on geospatial visualization tools, which is a fancy word for saying like we, we drew stuff on a 3d globe, right? So the early version of, of one of the apps use the old Google earth browser plugin. And later we switched to a library called cesium, which is similar to Google earth, but it's just JavaScript and webGL. In a browser, uh, and we could tell it, you know, put icons here, draw lines there, move them around the map as we get new data. Uh, that was a lot of fun to work on. I got to solve a lot of very interesting problems in that project.

Nice. Is that still available somewhere?

An internal proprietary company tool.

Yeah. Fair enough. Alright. Uh, last one. Uh, what is one thing you wish you knew before you started.

How to think through debugging, uh, debugging is something that unfortunately we do not actually teach as an industry. Um, I mean, there there's a lot of stuff. We don't do a good job of teaching as an industry, but. There are, there are a lot of basic principles of debugging that you can, like you can think through it's the scientific process, like understand how the code is supposed to be working, make an informed guess or hypothesis about here's the behavior I'm seeing. I think it's doing this, go through the code and inspect it and, you know, either confirm or disprove. Your understanding and repeat. And we don't teach people to think about how to debug. We don't teach people how to use the tools that are available to debug. Um, whether it be. Print debugging or your actual, you know, step in, step out, break points, step to buggers or cheap plug for my day job, the replay time traveling debugger like legitimately, this is a thing that people can get better at, and nobody gets told how to do this when they start working. So we all learn this the hard way over the course of our careers.

True. Absolutely. Yeah. I use console log for too many years before I started actually

Print debuggers and stepped debuggers are both viable.

Yeah, absolutely. All right. That's it. That's all the time we had way more than they were then when we had, um, can you tell people where they can find you? And if you have, if you want to plug your project again, go ahead.

Uh, I'm, I'm@acemarke on Twitter and Reddit and react to flux. I'm at mark Ericsson on GitHub and stack overflow. Uh, I generally hang out in the reactor flux discord on a, on a nightly basis and spend way too much time on Twitter. Um, What am I even working on right now doing my day job at replay Redux is in a good place. We just shipped react, Redux version eight, um, Redux toolkit 1.8. I've got a lot of stuff I need to work on. I just don't have the list of it off the top of my head right now.

That's all right, that's it. Thank you again, mark, for agreeing to come in and discuss. Uh, with us and the rest of you. Yep, absolutely. And the rest of you, that's it. Catch you on the next one?