Why You Should Use Redux in 2024 with Mark Erikson
===

Paul: [00:00:00] Hi there, and welcome to PodRocket, a web development podcast brought to you by LogRocket. LogRocket provides AI first session replay and analytics that surface the UX and technical issues impacting user experiences. Start understanding where your users are struggling by trying it for free at LogRocket.

com today. My name is Paul. And we are joined with quite the guest today. We have Mark Erickson. He is the Redux maintainer, senior front end engineer over at replay. io. And we're going to be talking about why you should use Redux in 2024. Now, Mark, you had a talk on this, why you should use Redux in 2024.

Where was that hosted if folks want to go like find the source for themselves?

Mark: Yeah. So ~I, ~I actually just did the talk twice at two different conferences. I did it at,~ uh, ~react connection in Paris in April, and then I just did it at react summit in Amsterdam a couple of weeks ago. ~Uh, ~the talk should be available. I know it'll be available,~ uh, ~through ~the, uh, ~the react summit get nation [00:01:00] video hosting site shortly.

~Um, ~also available in ~the, ~the live stream on YouTube that they did. ~Uh, ~I still need to get the slides up on my blog. I will try to remember to do that ~like ~hopefully later this afternoon. ~Uh, ~blog id software.com.

Paul: Awesome. Okay. ~Well, ~if people want to go check out the original source,~ go, ~go do so because there's a lot to cover here. As you know, our episodes are usually like 25 to 35 minutes. ~There's only so much we can. ~There's only so much we can pack in here. So maybe we can go through the intros and the high level stuff really quick.

Mark, how did you get involved in Redux? How did you become The maintainer,

Mark: Entirely by accident, I started learning React in the middle of 2015. ~Uh, ~I'd done some JavaScript, some backbone, some Google web toolkit in the previous few years,~ um,~ I had run into the pain points, heard about React and wanted to give it a shot,~ uh,~ started reading blog posts and working in chat channels just trying to learn on my own,~ uh,~ eventually started answering [00:02:00] questions that I knew the answers to, even though I hadn't even tried React yet,~ um, ~Finally actually tried React at the end of 2015, a few months after Redux had come out, at the start of 16, I actually volunteered to write an FAQ page for the Redux docs, because I was seeing the same questions being asked everywhere.

~Uh, ~I wrote that page, Dan merged it. ~Dan gave me, ~Dan Abramov gave me commit rights to the repo. ~Uh, and ~by the middle of 2016, about a year after Redux had come out, Dan was busy working on React at Facebook. And so he basically handed over the keys to the library to myself and another guy named Tim. It really took me a few more months before I felt like I was a maintainer.

~Um, ~and eventually it became an actual thing. ~Um,~

Paul: here. Cause it means ~like, ~it's purely out of passion and interest that you arrived where you are today. And that's where you can get the unbridled truth, right?

~It's there's, there's no, um, ~there's no sponsor sitting behind you with a big wooden bat,~ uh,~ in case something goes wrong [00:03:00] necessarily. So Mark. If people have not used Redux, maybe ~they're ~they're not even like in the react world yet. There's a lot of solutions out there. We're talking about state management, right?

There's ~like, ~I've used a stand. Personally, I know people have built their own state management, you have maybe you want to stay. Simple with context in react. What is Redux and how does it fit into this landscape of state management in the front

Mark: Yeah, so Redux is a tool for global state management, keeping state that basically any part of the application might be interested in and keeping it outside of the react component tree. As opposed to inside components in useState or useReducer. ~Uh, ~it focuses on having a single instance of a store object.

And you can't go in and just directly change the data yourself. Instead, the UI has to Dispatch in action, [00:04:00] which is a specific way of saying like trigger an event or something along those lines and say,~ like,~ here's something that happened. And there's a deliberate separation between the UI saying this thing occurred and the centralized state update logic actually saying, Oh,~ well,~ based on that, here's how we need to update the current state.

~Um, ~there's a lot of historical reasons why it's designed that way. Okay. Redux was originally created as an implementation of what Facebook had dubbed the Flux Architecture back in 2014. The idea of centralizing the state process, adding this indirection of having these action objects that describe a thing that occurred, instead of just saying state.

value equals 1, 2, 3. And this was done to be able to make the state update flow more predictable and not just allow any random part of the app to make changes. You could [00:05:00] always know exactly the sequence of this thing happened, go here, this piece of code updates it, and it would be very predictable. Yeah.

~Yep.~

Paul: or you mentioned Flux, like we're talking about separate end leafs of store. ~What do you, ~what do you think is the big? Take away on ~like, ~should one be used more than the other?

Is there a domain of application that one is stronger than the other? Or ~because, ~because you are the Redux guy, is Redux just the best?

Mark: Redux is absolutely not the best. In fact, ~that like, I actually like going meta for a second. ~I actually had to be convinced to do a talk with this title or theme in the first place. ~Um, ~historically, we've actually basically spent all of our time telling people when they shouldn't use Redux rather than actively trying to market it.

Now, ~I mean, ~I've also spent a lot of time defending it. There's a difference between ~like ~defending it and correcting misconceptions and actively trying to encourage people [00:06:00] to use Redux. So like I am very familiar with the trade-offs and the strengths and the weaknesses of Redux. I'm fairly familiar with the trade-offs and ~strength of ~strengths and weaknesses of a lot of other tools, even though I haven't actively used them.

I mean, number one,~ we've, ~we've always said ~like ~Redux is not ~like ~the absolute best tool for ~a situation in ~every situation. There's some situations where it's going to work very good. There's other situations where it might be useful, but you're going to have to ~kind of ~cram it in there. There's a lot of places where you really shouldn't be using Redux at all.

And. Frankly, some of the backlash that we've seen against Redux over the years was because people shoved it entirely too many places. It didn't belong, especially in the first couple of years of its existence when it was still the new shiny.

Paul: Got it. Yeah. ~I mean, you, ~you even mentioned in your talk specifically two years, 2016 and 2017, can you talk to me a little bit about what happened then in terms of overuse?

Mark: So ~very, ~very briefly recapping the [00:07:00] history, ha,~ uh,~ React came out in 2013. A year later, Facebook announced this Flux architecture concept. ~We've, ~we've been using React and we've been using some other patterns. We think this Flux architecture pattern works well in React applications. But they didn't publish an actual library for this Flux concept, just described it and published a couple of little utilities.

So the community ended up creating like 50 or 60 different competing implementations of this concept, each with their own little spins on it. I refer to that period as the Flux Wars. It was just like a year where everyone was coming up with their own Flux library. So Redux was originally created with A couple concepts in mind.

One, it's just another implementation of this flux architecture pattern that everyone else is already doing. And two,~ we're, ~we're going to take. [00:08:00] Some of the weaknesses that we see in some of the other Flux libraries and try to apply some functional programming principles and all that was really being done basically to create a demo for a conference talk,~ uh, ~Dan Abramov wanted to demo ~the, ~this concept of time travel debugging, except that he didn't actually have a tool that did it.

So a major driver for the creation of Redux was I want to show off a demo for a thing that doesn't exist yet. But in the end, like after two months of very rapid development, what Dan and Andrew created was a very specific Pared down architecture that applied functional programming concepts to the flux approaches and it basically killed off all the other flux library implementations that existed.

It was like the best version of flux that anyone had put together. ~The, you know, ~the early adopters, the advanced users in the community began jumping on [00:09:00] Redux. And somehow that transmuted within a year into people assuming that if you're using react, you must be using Redux along with it. Now there were a whole bunch of technical reasons why it maybe made sense to use Redux at the time.

~Uh, ~legacy context was kind of broken. So you couldn't really use it for passing variables down the tree. ~Um, the, there, there were just like, ~there were a number of pain points with using react. At the time and Redux was designed to work well with react and ~it, ~it solved some of the pain points that existed at that time.

And it was at a time when the react community was all in on flux as an architecture for building react apps.

Paul: perfect storm. Uh

Mark: that, everyone began to use Redux. Everywhere. ~And of course, like it's,~ it's the whole S curve adoption thing. ~Like, ~Hey, there's this new thing. It's awesome. Let's use it everywhere.

~Whoops. ~Whoops. Actually, there's a lot of problems with this thing. Okay. ~We've, ~we've used this for a while. [00:10:00] It's settled down. ~We've, ~we've found the right balance ~of, ~of using this tool. It's no longer as exciting, but we know when it works and when it doesn't. ~And, ~and Redux went through that just like any other tool.

There was also ~the whole, ~the aspect that. ~You know, ~early Redux was very boilerplate y. Somewhat by design,~ uh, ~Dan said early on that Redux and Flux will never be the shortest way to write code. It's designed to make it predictable. And that's true. The problem is the early docs showed patterns that made that boilerplate ~kind of ~worse and that people understandably adopted the patterns that were shown in the docs.

And then people made it more complicated by adding other libraries like sagas and observables for side effects. ~Um, ~writing a whole bunch of code for data fetching,~ uh, ~When TypeScript started to become popular, some of the early patterns for using TypeScript and Redux meant you were defining the ~thing, ~same thing, like three to four separate times.

And so using Redux was definitely becoming very [00:11:00] painful by the end of. 17 middle of 18, which is also when number one, the backlash started. And number two, other alternative tools that overlapped with Redux really started to become popular. Modern context for avoiding prop drilling,~ um,~ data fetching libraries like Apollo later on SWR and react query.~ Uh, ~other state management libraries eventually ~like, you know, ~Zustand, Jotai, MobX, ~like. ~There was a very definite shift in the attitude somewhere around 17 and 18.

Paul: I love hearing about this timeline, even though it was a little bit of a digression or tangent from what ~the ~the meat and potatoes are today, because ~I mean, ~a story like this, we're talking about a top tier technology used on top tier frameworks. And it is crazy. That's a crazy timeline mark. The way people behave is crazy.

And it ~kind of ~reveals a lot about how humans work as a whole, and the way we treat things and new and just new stuff that we have to [00:12:00] grapple with. It's very interesting.

Mark: honestly, one of my frustrations with both being the Redux maintainer and defending it along with. The web community as a whole is the recurring waves of, Oh, look, shiny new thing just came out. It kills previous technology. Like the mere fact that this thing exists kills the old thing. It's like that.

That's not how this works.

Paul: That's yeah. ~I mean, ~most of the web still runs on WordPress. I don't know what to tell you.

Mark: Hookball is still a thing.

Paul: And it's popular. ~Like ~if you go look at the numbers,~ it's, ~it's definitely not dead. Ah, all ~right. Well, let, ~let's talk a little bit about Redux toolkit. ~That ~that's one of the stars of the show today. What is it? Is it something that's like adjacent to Redux? Is it part of the library? Why should somebody listen to it?

Mark: ~There's, ~there's multiple answers to that. ~So, ~this actually directly follows on from the timeline that I was giving. By, ~by mid,~ mid, late 17, early 18, I'd been the maintainer ~for a couple year, ~for a [00:13:00] year and a half ish, and I was getting tired of hearing the word boilerplate. And seeing people's pain points with using Redux.

So I started up a discussion thread saying, what can we do to make Redux easier to use and try to address these boilerplate concerns. And over the next two years, we prototyped and built out a library that we eventually called Redux toolkit. And the idea was we want to have built in. that do all the common things that people do in Redux apps, but built in and simpler and easier to use.

And ~like ~the Redux community had already written thousands of Redux related add on packages for a while. I was maintaining a very large list, tracking every Redux related library that I could find. And a lot of them were like auto generate action types for ~Your, ~your reducer code or auto do data [00:14:00] fetching or stuff like that.

And so we were seeing. Lots and lots of duplicate solutions for the same problems over and over and over. So it was clear, these are the kinds of things people want to do in Redux apps. These are the homegrown solutions they keep coming up with. How can we provide official solutions for all these standard usage patterns in Redux?

And that way. People don't have to keep reinventing the wheel it officially, like with it being official, people will hopefully adopt these. It'll make Redux apps more standardized and easier to understand instead of everyone doing their own thing. And ultimately it'll actually, in the end, make it easier for us as maintainers because people will stop coming to us with some of these same complaints like, whoops, my UI didn't re render.

Yeah, it's because you accidentally mutated your state again.

Paul: So common [00:15:00] functionalities, common bugs, like you just mentioned,~ or, ~or misconceptions about how it works. It helps bootstrap you. And you ~kind of ~sourced when needed to do by all these community plugins on this giant list and for and for thought. Okay, got it. What can we dig into some of what it does? ~Like ~if somebody goes to Redux, and they're still learning about what it does, okay, state management, I get it.

Maybe it's a little hard to integrate. ~I ~I'm hearing there's boilerplate. But there's this toolkit. How is the toolkit going to bring me closer to that point of operable success?

Mark: Yeah, so structurally there's the original Redux core package, which was always incredibly minimal. You have the create store method, which creates a Redux store,~ uh,~ combine reducers, which is the standard way to collect all the state update logic and prepare it for use in the store. And then a couple other tiny utilities.

And that's it. Like you bring everything else, the application, logic, your own abstractions, whatever else you want on top of that. So the Redux toolkit package [00:16:00] at Redux JS slash toolkit is effectively a wrapper around the Redux core. In fact, it uses like the create store method internally. But in practice today, we actually don't want anybody using the original Redux core package by itself from our standpoint, Redux toolkit is.

Redux today. Like ~it is, ~it is the correct way to use Redux. If you're still using the original package by hand, hopefully you're on a very out of date code base and you need to migrate and you definitely shouldn't be starting any new projects with just the original core. Package. So I actually rewrote our tutorials in 2020 to teach Redux toolkit as the default.

~Um, ~so ~it's, ~it's been, ~you know, ~like four plus years now that we've been teaching that as the standard way to write all Redux logic in your applications. [00:17:00] Silence. Silence. 

Paul: other paradigms and mental models put forth using Redux? Or is it ~sort of ~like a black and white situation where you have to buy into Redux? this like best set of practices and principles. And I'm thinking like there was one startup I worked ~for ~for a bit where we used observables underneath or on top of Redux and had this like declarative store definitely ~was, ~was not using the toolkit.

Is this something where you would say,~ well,~ let's rethink about using observables entirely, or could they be complimentary?

Mark: ~there's, ~there's multiple different aspects here. ~Um, ~the first off, like in terms of say, migrating a code base from the legacy handwritten Redux patterns to modern Redux toolkit, you can absolutely do it. You can do it 100 percent incrementally. You can do it on like a file by file basis. All of Redux toolkits pieces.

Our Redux, it's the same concepts that we're always taught writing [00:18:00] reducers for updating state, dispatching actions, having action creators using thunks for fetching data. It's all those same concepts, just with a simpler syntax and more pieces built in. So like our standard migration recommendation is.

~Like ~if you have an existing Redux application, ~you know, ~like a hundred thousand lines, whatever, start by swapping the one store setup file to use RTKs configure store doesn't change the behavior, although it will add like a couple more,~ uh,~ development mode, debug checks for things like accidental mutations,~ um,~ probably end up deleting like 30 lines of code in that one file.

Then pick one reducer. And any of the associated action setup that goes along with it, replace that with Redux toolkits, create slice. All the other code continues to work exactly the same way. You probably just deleted 75 to a hundred lines of code from that one file. And then you just ~kind of ~keep [00:19:00] repeating incrementally until all the old Redux logic has gone and you're left with just the Redux toolkit stuff.

~Um, ~in terms of like side effect things, Redux has always allowed plugging in your own side effect behavior to the store. That's why we have things like observables and all in various other, ~you know, ~add on libraries that people had built. So ~it's, ~it's always been. Your preference of how you want to manage side effects in the application.

So there's nothing wrong per se with using observables in a Redux application. ~Um, ~that said side effects were a very big term back in ~like ~15 and 16. And in practice, what we've found is that. In reality, like 95 percent of the side effects in the typical client side application are just fetching data from the server and caching it.

And that's why we have libraries like Apollo and React Query today. Because data fetching and caching is a Common thing that you do. And it's a different [00:20:00] mindset from managing state on the client side. And so that's why we actually built an equivalent data fetching and caching library into Redux toolkit,~ uh, ~that we call RTK query.

It's optional. You are not required to use it, but we strongly recommend that people should use that as the default approach for fetching and caching data in Redux apps.

Paul: That's so cool that you guys have that built in because you mentioned Apollo. ~That's an ~Apollo is awesome. ~Like ~if you have a graph API to ~like ~work with power to you, man, but ~like, ~having ~a ~piece together every time you have to build in a new dependency that's ~like ~strictly different, such as SWR, also great, fantastic to use, but now you have another thing.

So now we can get all that out of the box of RTK. Okay, very cool. ~And, ~and that's strictly different than the store. ~That's, ~that's where ~you're, ~you're calling this out, Mark, where you're like, Hey, caching and store state two different things. ~And, ~and you got to treat them differently.

Mark: now ~the, ~the mechanism is still [00:21:00] Redux, like RTK, so RTK, Redux toolkit includes a method called create async thump, which just standardizes the pattern that we've always taught in the documentation of you have some code that is going to dispatch an action before making a request. And then it so you can have ~like ~a loading spinner or something and then it's going to dispatch another action after the async request comes back saying either it succeeded.

Here's the data or it failed. Here's the error. So create async thunk standardizes that part of the pattern. You can use that code yourself, but ultimately RTK query does that work for you internally? So you don't have to write the thunks or the reducers or the logic to manage the loading spinners or even writing the hooks and the selectors and the use effects ~to do ~to do the dispatching and read the data.

It's all the same patterns that you always had [00:22:00] for writing data fetching code in Redux, except now RTK Query has done literally the exact same thing for you under the hood. All you say is here's my Get Pokemon endpoint and it automatically generates some hooks for you. And you set up RTK query once and you get the hooks and it just works.

Paul: Now you mentioned actions. This is all surrounding actions and how it handles that you switch, switching focus a little bit. So zoom out, right? You mentioned,~ um,~ handling actions as events.~ What, ~what is the event where, is this like a dom event ~and, ~and what do you mean by that?

Mark: So this goes all the way back to that flux architecture concept. ~Um, ~and ~so, ~So a little bit more history prior to react and flux. ~Uh, ~some of the major common web frameworks were,~ uh, ~early Angular one or Angular JS,~ um, ~Ember, and then Backbone and Backbone was ~kind of ~like ~little, ~little smart wrappers around JavaScript [00:23:00] objects and arrays and ~like ~scoped jQuery pieces of the UI and every one of those Backbone types had an event emitter.

~So, ~for example, if you had like a person model and you called person dot set first name and then a value, it would trigger an event on itself called change colon first name. And so the UI pieces would listen for those change events coming from the data. So that if you have like ~your, ~your people list and a people list item view, it would watch for changes in like first name or last name or age to figure out, Oh, Hey, I need to update my little piece of the UI, the equivalent of calling like a set state in react.

The problem is that any piece of code and backbone could be watching for an event, and then it could just trigger some more random logic. Which might set state and that, or it might trigger another event. [00:24:00] And the next thing ~you know, ~you got this whole random chain of events ricocheting around the app.

And that was one of the things Facebook found was it's very hard to understand the data flow in the application when you can just have arbitrary event callbacks kicking off anywhere. And so part of the point of this flux architecture was ~we're going to, I'm going to~ centralize the data update patterns into a single thing called the dispatcher.

And every state update has to start by making a little JavaScript object that has some kind of a description. Of the thing that happened. So there's like a string field that is like a name, like to do added. And then whatever data fields are appropriate for that kind of a thing. And so the UI just makes this little action object and sends it over the dispatcher.

And then the dispatcher is responsible for passing that to the actual logic that does the state updates. And so ~it's, ~it's very orderly. [00:25:00] The UI always makes the action object, sends it to the dispatcher, state gets updated, and then the UI gets the notifications of the state updates and can re render. So with Redux, that kind of got condensed into, there's not like a dispatcher and multiple little stores, there's one store, and you call store.

dispatch. But the concept of having that Action object with some kind of like a human readable name describing a thing that occurred was something we inherited from the flux architecture. And so this has multiple benefits and some various other trade offs. Redux was designed to have dev tools where you can see a list of all the actions that occurred.

And so I, as a developer, especially in working locally, ~I can look ~I can open up the dev tools, look at the actions list and see, you know, to do added, to do added, to do [00:26:00] toggled, to do deleted. And that tells me exactly the sequence of things that the user was doing. In my application. You also have the ability to inspect the action objects and see what data they contained.

You can see what the difference in the state was after the action got processed or what the final state was at each action. And so having that separation between this thing occurred due to the user, like clicking the button and here's a description and then how it's got updated, make some of that debug ability possible. So, uh, sorry. So getting back to the actual question, actions as events. Redux doesn't care what the actual names of them are. You could write it as capitalized to do underscore ~like ~add underscore to do. You could write it as camel cased add to do or camel cased to do added. Past tense, or even just like [00:27:00] Fred, like the name of the string doesn't matter.

All that matters is ~your, ~that your reducer logic looks at it and says, Oh yeah, based on that thing, I need to make these updates. So you could have actions like set first name, set last name, set age. But we found ~that ~that's actually a pretty bad pattern because number one, it leads you to defining. A lot more distinct action types, which means more code that you have to write.

It also leads towards the UI side, doing more ~of the, ~of the work I've seen a lot of people try to grab the existing state, do all of the objects spreads to copy it and update it in a click handler in a component. the entire new state. To the action that they're dispatching. And then the reducer just says like return action dot payload or something.

And this is bad because [00:28:00] we're actually getting right back to having the UI doing all the work of updating the state when we were trying to separate it. Before, and especially in the case of Redux toolkit, you're throwing away the ability to use Emmer for simplifying the immutable updates in the reducers.

And you run the risk of dealing with stale state. ~In, ~in a, ~you know, ~component click handler, whereas if you just dispatch an action with the most minimal possible data, like to do added text by milk, then the reducer logic. So I look, I've got the entire list of to do's here already. I just call ~like, you know, ~state dot push new to do, and ~it's,~ it always has the latest data.

It can use the simpler immutable update logic. And ~we've, ~we've kept that separation. Between the UI and the data updates. So like mental model, describing it as a thing that occurred past tense leads [00:29:00] you to a better approach to writing the code.

Paul: That's super interesting. ~So, ~because I love to write,~ um, you know, ~set, whatever, whatever, whatever. But what you're telling me is you'll have a less fragmentation of your mental model, less fragmentation of the edges. Of your state. If you write everything as what is going to have, what happened in the past and then acting on that versus actions to be invoked,

Mark: Yeah, it's,

Paul: got

Mark: it can be ~kind of ~hard to wrap your mind around and ~like, ~even I don't manage to always like fully put it into practice, but if you can use it as ~kind of ~like a guiding principle ~that you would ~that you try to work towards when you're writing the code, generally, it leads to better code as a result.

Paul: And you mentioned emmer, which is the immutable,~ uh,~ it makes sure that there are no mutations when you're updating your state. That's my understanding of it. I might've botched that. Can you tell me a

Mark: Yeah, so JavaScript by default is [00:30:00] mutable. Every object can be changed, modified, fields added, fields deleted, fields, field contents changed at any point in time. And so historically, the number one bug in Redux apps was I accidentally mutated some of the existing state that was already in the store and that causes problems.

~So. You know, ~for example,~ um, you know, ~array dot sort mutates the existing array. So ~like, ~if you grab an array into a component and then you try to sort it without making a copy first, oops, you just actually mutated your state or you're trying to. Update like a three level nested field. in order to do that, you have to write a whole bunch of nested objects, spreads dot, dot, dot, state, comma, state, dot to dues, dot, dot, dot, state, dot to dues, comma, et cetera, et cetera.

And it's, it's ugly. It's long. It's painful to read, painful to write. And it's very easy to accidentally forget to do something. So we, I built the [00:31:00] very first prototype of Redux toolkit around this library is a way to simplify doing immutable updates in JavaScript using proxies. So you have a callback, you have a function called produce, you pass in.

Your current data, like a Redux state or just a whatever JavaScript object or array, and then you give it a callback and the callback function runs and receives what looks like the exact same state value, but it's actually been wrapped in a proxy, and that means that Emmer can track every single nested field that you try to access or that you try to update. So inside of this callback, it is safe to truly mutate. That draft value. So you can write state dot nested dot field equals one, two, three, and it's okay because you're not mutating the original plain JavaScript data [00:32:00] and emmer is tracking all of these mutations. And by the time you're done, it says, okay, here's all the fields that got updated.

We are going to do all the immutable updates internally, automatically, as if you had written all the object spreads yourself, but you didn't have to. And so it drastically shortens the code, makes it way easier to read, way clearer to understand what the person's trying to update here. And it basically eliminates accidental mutations in that code.

So we built Redux toolkits, create reducer and create slice methods around having emmer baked in by default. Like it's actually a very, very opinionated thing. You can't even turn that off. If you're using create slice. You're already inside of that emmer callback, so you can safely mutate, quote unquote, this state value as much as you want, and it's actually effectively [00:33:00] impossible to actually accidentally mutate and have bugs.

Paul: would you say that? Understanding, ~you know, ~this idea of immutable state, pure functions, which we didn't really have time to touch on today. But like these fundamentals, should somebody go read about them before? ~Okay, I didn't even have to finish my~

Mark: So ~this, this is, this is ~really gets into the aspects of. Teaching an abstraction as the default. So in order to use Redux toolkit effectively, you do need to understand some of the core concepts. ~Like, you know, ~what is ~a, you know, like ~a pure function, you know, values in result out does not affect, ~or, you know, ~anything else within the application.

~Um, ~or immutability, like the fact that you need to be able to make copies of objects, don't change the originals. ~Okay. ~And Redux toolkit is an abstraction. Like when you're using create slice, you don't see emmer. And so I've always had this bit of a fear that, ~you know, ~someone might learn Redux through Redux toolkit and think like I can write state.

[00:34:00] nested. value equals one, two, three, any time, and then end up in a older style Redux code base and think they can do that and not realize ~that ~that only works because of Emmer's magic behind the scenes. There's like the, really, the only answer to this is education. And so ~when I, ~when I wrote this essentials tutorial in 2020, that teaches RTK as a default, I very clearly and loudly put sections in the first couple pages of the tutorial that emphasize with ~like, you know, like ~bright red.

~You know, ~warning sections like, look, you need to understand this concept of immutability, here's what it means in general. And remember when you're using create slice, the magic only works here because of Emert. . ~Um, ~does that help everybody? I don't know how many people actually read art tutorials. Not enough, but ~like, ~you do need to understand just enough of what is happening below the [00:35:00] abstraction layer.

Paul: ~Mm hmm.~

Mark: Like for the most part, you can just use RTK, you don't have to worry about it, but ~it, it's, ~it's very true that with any abstraction layer, if you understand ~like ~just that next level down, so that you understand what the abstraction ~ISS ~doing for you, then you can use it more effectively.

Paul: Got it. And you mentioned ~your ~Your guide again. Gosh, the time flew out from under our feet here. So I'm going to start switching gears, the transmission into the wrap up phase, which means that we should mention the guide. ~Like ~if people wanted to get involved with RGK, where do they go?

Mark: Okay. So ~we, ~the primary documentation site is Redux. js. org. ~Um, ~for historical reasons, we actually have three separate documentation sites because we have three different libraries and three different GitHub repos. So Redux. js. org, React Redux. js. org, and ReduxToolkit. js. org.~ All the, ~all the tutorials.

And getting started information is in the [00:36:00] core site, Redux. js. org. ~Um, ~the API references for the additional libraries are on the React Redux and Redux Toolkit sites. ~Um, ~we have two different tutorials to get people started. There's the Essentials tutorial. Which is, we're just, we're going to dive right into using Redux Toolkit.

We're not going to worry about how it works underneath. We will show you the right way to use Redux, follow along, build out a vaguely plausible example application that just so happens to show you all the pieces inside of Redux Toolkit and how to use them correctly. ~Um, ~And then you can go off and start building stuff.

There's also the fundamentals tutorial, which says we're going to, we're going to go all the way down to the beginning, no abstractions. Here's how you write everything by hand. Here's how all the pieces work, build it up over time. And then at the very end show how Redux toolkit simplifies all those things.

Now, this actually ties in to what I've been doing most of this year. ~Um, ~I wrote those tutorials in 2020. So if you have any questions, [00:37:00] feel free to reach out to me. And ~they're, ~they're very good. I'm still very proud of the work that I did, but a number of things have changed. ~Uh, we ~we've added some more pieces to, ~you know, ~Redux toolkit in the last couple of years and the tutorials themselves are written in plain JavaScript. And I finally made the decision recently that it was worth teaching at least the essentials tutorial using TypeScript. For the complete example app every step of the way,~ um, my, ~my concern has always been that ~like ~new beginners, especially people ~like ~coming out of boot camps,~ uh, ~like they're already overwhelmed by here's a month of javascript, a month of react, a month of Redux go and like, like.

They shouldn't be getting thrown into Redux that early in the first place, but that's out of my control. ~But ~so ~like ~throwing TypeScript on top of all that, I've always been concerned that it's just going to make it that much harder to learn, but we want people using TypeScript with Redux. Redux toolkit is designed to work well with TypeScript and the [00:38:00] benefits you get.

In terms of preventing common mistakes are absolutely worth it. So I finally decided it was worth just ~like ~redoing the tutorial from the beginning TypeScript for every single commit of the example application, all the explanations of how to set up the TypeScript usage in a Redux app and use it, ~you know, ~all the way through was worth doing.

~So. ~I've been working on that intermittently over the course of the year. ~Um, ~it's been busy conferences and personal life and other stuff going on. I am actually ~very, ~very close. ~Uh, ~I am like.~ I, ~I had the example app done a couple months ago. I've been intermittently working on the content updates, mostly on flights to conferences over the last two months.

~Um, ~I have, I'm like 80 percent of the way done updating the last page. And today's Friday. Like I'm literally hoping that tomorrow afternoon I can sit down and finish updating that page and have a first draft complete. And then maybe even ~like ~have this done and live like [00:39:00] a week or two after that. So ~like, ~by the time people actually hear this podcast, it might actually be done.

That would be fantastic

Paul: that's good timing.

Mark: be like a huge load off my mind. And then I will go find other things to self responsible assigned to myself.

Paul: And can people find that tutorial where the JavaScript is just going to

Mark: Yeah, so, yeah, so ~if you, ~if you go to Redux. js. org, the word tutorial in the header bar takes you to page one of the essentials tutorial.

Paul: Awesome. And we're 40 minute ~mark ~mark. Can you give us in one minute something you're ~looking forward ~looking forward to? contributing yourself or that you see the community gearing up to contribute to Redux toolkit in the next year.

Mark: So the, it's been amazing how much adoption we've had for RTK query over the last three years. ~Um, We have, ~we have probably at least ~like ~150 open issues regarding RTK query feature requests, bug reports, et cetera. Last year, I spent the entire year working to ship [00:40:00] RTK 2. 0, which was package updates for all of the different Redux packages.

And I had to defer doing any actual work to improve RTK query because it was just too much to think about. ~Um, ~and then I spent the first half of this year working on the tutorial. ~So. ~My goal, and this goes back to me assigning myself work to do, is that once the essentials tutorial is out the door and I've helped merge some outstanding tooling PRs that have been sitting around for a while, I will start to look at some of the open RTK query feature requests, things like,~ uh, ~infinite pagination support, or maybe suspense support,~ um, ~ Maybe a little bit of normalization behavior.

I don't know. ~Like ~there's tons of things that our users have asked for to improve RTK query. ~Uh, ~which frankly can be ~kind of ~overwhelming. Like there there's, we're only, you know, like actually build out ~like ~a handful of them this year, if at all, but clearly people want to see improvements to RTK query.

So we're going to try to [00:41:00] work on this.

Paul: Awesome. ~I mean, ~I can't wait for the tutorial that's going to be in TypeScript because ~it's, it's, ~it's really great to see how you can leverage TypeScript. ~I mean, ~recently I've been using TRPC and it's just been awesome for that same use. So we got the TypeScript tutorial coming. We got,~ uh,~ RTK query is going to get some love and affection.

~Uh, ~it sounds fantastic. ~ ~ Well, Mark, this has been a super engaging podcast. ~It's, ~it's awesome to have somebody who's so deeply involved with a library that probably touches, like you mentioned, more apps than you maybe would say is appropriate, but most apps out there. And,~ uh, it's, ~it's great to have that insight.

So thank you so much for your time. ~It's, ~it's been an absolute pleasure. ~Um,~

Mark: I did warn you that this could have easily been a three hour discussion.

Paul: you did. Before we started recording, Mark was like,~ uh,~ so I see where you have ~like ~a one hour time slot. ~Yeah, we could. ~So hopefully we'll have you ~gone~ again on in the future and we can revisit some of these and see where the RTK has gotten. Awesome. ~Well, ~thanks so much for your time.

Mark: Thanks. Appreciate it.