Mark Erikson === Noel: [00:00:00] Hello and welcome to Pod Rocket. I'm Noel and rejoining us today is Mark Erickson. , Mark's a senior front end engineer at Replay, , Redux maintainer, creator of Redux Toolkit. , and he's here to talk about modern redux and the Redux Toolkit at large. , welcome back to the podcast, mark. Mark: Thanks. Glad to be here. Noel: Awesome. Yeah. So I guess, yeah, before we jump in and start talking about, , Redux and what's going on, , can you . . Just give us , your background and brief maybe for users that didn't get the last episode, or, , it's been a while for 'em, , what you're doing at Replay and just how maintaining Redux is going overall. Mark: Sure. , so I'm a senior front-end engineer at Replay. , I've been there for just over one year and we are building a time traveling debugger for JavaScript applications. , I've spent a lot of my career debugging and trying to investigate problems, I'm biased because I work there, but I honestly wish I'd had this tool much earlier in my career. , being able to make a recording of a bug and then go in and jump to any point in time and add print [00:01:00] statements to any random line of code and see how many times that code executed, , is just so amazingly helpful for solving problems and There's even been a couple redux related bugs where, , like wearing my Redux maintainer hat, I was able to make some recordings and go and debug them with replay. And I honestly don't think I could have figured them out any other way. So I am incredibly excited about the tool that we're building, , Noel: yeah, for sure. , so like you mentioned your replay work there. Tell us about how you got into that space and what you're spending your time on there Mark: Yeah. So I'd spent, , my entire career about 14 years at a large government contractor prior to that, and was just, , ready to do something new. , Announced at the start of last year, I was, , open and available and looking for new opportunities. , had a whole bunch of companies contact me, , went through the job search process for the first time ever. And admittedly, my job search process was probably a little bit different than most other people cuz companies were contacting me Noel: Was your redux work, was your work on a large open source, [00:02:00] visible project? Do you think that led to, , having companies Mark: Oh, yeah. Oh yeah. Like I have established, , an online reputation as Redux Guy, as someone who usually knows what he's talking about. , and for generally being helpful. And none of those would be true if I had never gotten involved with Redux in the first place. I do this because I want to support. The community of Redux users Noel: No. Totally. Totally. Yeah. yeah. Cool. Again I'm super happy you're, , joining us again to, to talk about what's going on, , with Redux and what's coming up in the future, to maybe, , I don't know, add some context for users who like maybe aren't super. Super familiar. , they're not like React users or they haven't used modern Redux in a while. Can you contextualize that? Tell us like what Modern Redux is? Maybe give us like a brief overview of rtk, , and just some of those, , slightly newer features that people might not be using currently. Mark: Sure. , so Redux came out in 2015, , created by Dan AOV and Andrew Clark, and became very popular. Over the next couple years, , everyone began to assume that if you were building a [00:03:00] React app, you had to be using Redux to actually manage the state on the client side. And, , Dan was only involved with Redux for one year. And then he handed off the maintainer ship to myself and Tim dor. And the problem, like every technology goes through the whole like S-curve adoption thing. , here's this new thing, it's shiny, let's try it out. A bunch of people jump on it, they build things with it, and then they find out , , all the cons or the trade offs later on over time. And so Redux was put in a lot of applications that never needed it in the first place. , Redux was used in a lot of ways that it shouldn't have been. For example, there was a fairly popular library for managing your form input state with Redux, and it's creator Eric Rasmussen has since disavowed that and said no, this was a bad idea. Don't do that. , and the ecosystem has changed. , And we've switched over from thinking about client side state management to more about like server side data fetching and [00:04:00] caching as the big problem that we really want to solve. And so the early redux patterns were very verbose and there were good reasons for those. , but it also meant you had to write a lot of extra code to do, , even relatively straightforward tasks. And there was. Basically no functionality built in Redux was a very low level of primitive. And so it was up to you to build all the actual functionality on top of that. And so by, , 27, 20 18 people were, , tweeting, , about how, , how much they hate Redux and, , other libraries. So much easier to use. And, I switched over to. Fetching my data with Apollo or React Query and I deleted , five to 10,000 lines of READEX code. And that's actually a very fair assessment because especially for data fetching, you would've had to have built all that functionality yourself. And so if you switched to using a purpose built library for that use case, then it probably is gonna be a lot shorter. , but it's also [00:05:00] true that. A lot of the verbosity around redux was not necessary. , in, in some of my talks and articles, I've used --- Mark: the phrases, , inherent versus incidental complexity. , so Redux was not designed to be the shortest way to rate code for updating and managing state. It deliberately adds a level of indirection having, , this idea of having to dispatch an action and keep your reducer logic separate, is always going to be more code than just saying, , state value equals 1, 2, 3. That, that's intentional. That is part of red's design. And if you take that away it's not Redex anymore. But then you have to think about what is the purpose of why we do that by adding that level of indirection it gives us a number of benefits. Number one, like all the update logic is consistently in one place. Architecturally, if I open up a Redux code [00:06:00] base, the first thing I do is go to look at the reducer functions, because those tell me what state is in the app, how is it being updated, what are the actions, , what's the name of the things that happen? In the app conceptually, and that gives me a very consistent pattern to look at and understand what's going on. , it also enables, , the redux dev tools, being able to see a list of things that happened in the app over time. See the payloads of each action, see the diff in the state, see the final state, and adding that separation. Makes that possible. So it's trade-offs. You add the layer of indirection, you gain the benefits of, , predictable architecture and being able to see things but beyond that, , the, like I said, the early patterns were very verbose. You had to, , write all these action type constants and action creator functions. And , the common pattern was to split your logic across like constant [00:07:00] slash to-dos js and. Reducers slash todos js and action slash todos js, and that wasn't required, but okay, fine. It was in our docs and most people did that. And so we came up with Redux Toolkit as a way to write the same redux functionality, but with way less coat. So we basically looked at what are all the problems people are trained to solve in redux applications and how can we provide APIs that make each of those tasks simpler to do? So we put out Redux Toolkit 1.0 in October, 2019. , I readed our tutorials in 2020 to teach that as the default standard way to write Redux code. And it's been a huge success. , and R T K includes a dependency on the redux core. So every R T K download is a download of Redex. , but We routinely get people telling us how much they [00:08:00] enjoy working with Redux Toolkit, , even if they like hated writing old school redux or, I see threads on Reddit with people asking, , which state management library should I choose? Or, , Redux versus other library of the week and people are popping in and saying, I really enjoy a Redux toolkit and you should use it without me having to jump in and prompt them about it. It's solved the boiler plate problem. It solved a lot of the common bugs that used to pop up, and it has basically succeeded in the goals that we set out for ahead of time. Noel: Nice. I have one technical function that's going to expose my, like unfamiliarity with old Redux a little bit here, , so I used view a lot more, , , in the past few years, , for side projects and stuff where I was using VX as a state manager and they had these map functions that you could use to inject, , like your increment, your Mutators and your gitters and all these things into your view components. Did React have or does it have something akin to that, , like that , the toolkit , replaces or was that never really a paradigm in [00:09:00] react at , all? Mark: With Redux, there's two and a half or three separate pieces depending on how you're slicing it. So you've got your actual Redux logic, creating the store, defining the reducers, and the actions like that. That code is UI agnostic. Redux itself knows nothing about your ui. You can use the exact same Redux store with React, with view, angular, vanilla js, jQuery in a node backend, wherever. It's just. Plain JavaScript, but we do assume that the vast majority of our users are using Redux with React as the ui. And so there is a specific React Redux library that provides the bindings that allow your React components to interact with a Redux store by reading state values, re rendering with those change and dispatching actions. React Redux is entirely dependent of the logic layer. You can use React Redux with, , the [00:10:00] old school way of writing Redux code. You can use it with modern Redux toolkit code. , the UIs part doesn't care because it's all still redux either way. Having said that, react Redux itself also underwent a usage in a p I shift in 2019. , what we'd always had from the beginning was an API called Connect, which used a react pattern called higher order components. So the idea is you write what was typically referred to as like a presentational component, some component that just gets data and callbacks as props. It knows nothing about Redux. Everything gets passed in. And then you define a couple parameters for connect called Map State to props and map dispatch to props. And those allow you to extract data from the Redux store and pass it in as props to the React component and provide [00:11:00] functions that dispatch actions , when they're called. And pass those in as props. And, , higher order components were a very standard react pattern for many years. But in late 2018, the React team introduced hooks. And so every library began figuring out, okay, how can we provide our functionality with react hooks in some way? And so in the first half of 2019, we rewrote the internals of Connect. To be built using hooks, so same public api, different internals. And then we figured out what is our new public hooks based API going to look like? And so we came up with a couple hooks called Use Selector and used dispatch and used Selectors. Just grabbed this data from the store. Rerun when it changes. Use dispatch is literally just return store dispatch. Noel: Yeah. Mark: gives your components access to the state and dispatching. And similar to, , Redux Toolkit, those are now the [00:12:00] standard pattern we teach for working with Redux in React. So we got, , two different independent axes here, but today we teach Redux Toolkit and React Redux hooks as the steered way of rating. React plus Redux apps, and both of those are much simpler to work with and use than the older style patterns. Noel: Just a quick pause here to remind you that Pod Rocket is brought to by Log Rocket. Log Rocket can help you understand exactly how users are experiencing your digital product. With session replay, error tracking, product analytics, frustration indicators, performance monitoring, UX analytics, and more machine learning algorithms service the most impactful issues affecting your users so you can spend your time building a better product. Rather than hunting through tools, solve user reported issues, find issues faster, and improve conversion and adoption with Log Rocket. Thank you for giving us some background there. So can you tell us a little bit about, , , specific features and then what is changing in the near future? I saw that we have,[00:13:00] , redux, , toolkit 2.0 in, there's a few alpha releases, right? , since the beginning of this year. , and those are pinned two, the Redux 4.2. Whatever to like 5.0 under the hood. Is there anything else big that's motivating that change? Are there big feature sets or like library changes that are necessitating that or is it mainly the redux version? Bump? Mark: Oh there's a bunch of stuff going on. , see, let's, let me do a quick run through, like what is in Redux Toolkit right now, as of our 1.9 versions, API listing. The bread and butter of Redux Toolkit are the configure store and create slice functions and these are what we really expect, basically everyone to be using. So configure store wraps around the core libraries, create store api, but it sets up good default options. Right away. And it makes it very simple to do. So the old style create store, you had to do like this, , 20 or 30 line dance to get [00:14:00] all the configuration options, right? And granted, you're only doing that once per application, but it was always annoying to have to set that stuff up yourself. So configure store out of the box makes it really easy to combine the reducers, add the redux thunk middleware, configure the redux dev tools for being able to view changes in the application. , and it makes you just pass all these in as a couple of object, , options, style arguments, and it's, it, it just does all the basic standard set up work for you. And it even adds a couple of development mode middleware that check for common mistakes like accidental mutations or non serializable values in the store. are all the things you would've had to set up yourself anyway. Let's just have one API that does that work by default, so you don't even have to think about it. With reducers and actions and stuff. I said a minute ago that the old patterns have you writing a bunch of you cons, add underscore to do equals quote, add underscore to do, and then [00:15:00] like an action creator function that uses that to constant. And then the reducer has a switch statement that looks at the constant and then you have to do a bunch of spread operators to copy the state. And again, there were good reasons for all those patterns, but it was always a pain to work with. You have to write so much redundant code and it was always so easy to accidentally mess up the immutable update operations, mutate data. So Redux Toolkit has an API called Create Slice that again basically does all that work for you. So you pass in an object, you give it a string name field, the initial state for the reducer. And then an object full of what we refer to as case reducer functions. So the idea is they're supposed to handle one action, similar to a case statement in a switch. And their job is to update the state when that action occurs. , to-dos added, to do completed stuff like that. But what's really nice here is [00:16:00] inside those reducers, you can write code that appears to mutate. The existing state value, and that's because Redux Toolkit includes an amazing library called ER Inside, which wraps your data in a proxy object. Tracks the mutation statements and then converts all of that into a correct and safe immutable update. So instead of having to have , five levels of nested, , spread operations and array concat and maps and slices, you can just say, , state dot sum dot field equals 1, 2, 3, and it just works. And the code is simpler and it's shorter and it's easier to understand what you're trained to do. And basically makes accidental mutations pretty much impossible. And those were always the number one cause of redux bugs. So it's just a huge win across the board. And on top of that, create Slice will automatically generate action type [00:17:00] strings internally, and it generates the action creator functions. Corresponding to each case reducer, and if you're using type script, all the types get passed through, right? So you don't even have to think about the action type strings. You get your action creators for free and your rating code that just says, here's a function, mu mutate my state, and it all just works. Noel: Yeah, because you can export from, or whatever, from the slice. Then you can just pull off the actions, object the name of those functions and use them wherever. So it makes it super clean, Mark: yep. So configure store and create Slice are the two things that we really expect everybody to be using as a baseline. And the rest of it is , , pick and choose based on what problems you're trying to solve in the app. So there's create Async Thunk, which, , abstracts the common pattern of Make an Async request. Dispatch , a loading action beforehand and then success or failure afterwards and use that to track, , loading status and you maybe show a [00:18:00] spinner or something. So it does that work for you. You just provide a function that makes the async request and returns the result. It generates the action types and dispatches them as necessary. Again, standard pattern that everyone was doing, we just made that built in. There's, , create entity adapter. So our docs had talked about this pattern of normalizing data. So you take like an array of items and convert them into an object where the IDs of each item are the key. So you can look up an item directly and , , We had never had anything built in to help with that. So create entity adapter gives you little pre-built reducers that automatically do your crud style operations. So , insert all these things, add a thing, remove those things, whatever. , again, just like common things people want to do with data in the Redux store. And then there's two relatively newer additions within the last couple years. I said earlier that. These days, people are much [00:19:00] more concerned with data fetching and caching server state than they are necessarily with, , managing state on the client. And so there's all these great libraries like Apollo and React Query and S W R and Urkel. And so we took inspiration from those and we built a purpose-built data fetching and caching a p i into Redux toolkit. And we call it R TK Query. , . , and so it is a data fetching and caching solution built on top of the other pieces that are included in Redux Toolkit. So you, it uses thunks and slices and selectors and stuff inside, and the idea is that you define a set of end points, which could be, , rest based GraphQL or even just like an arbitrary async function. And it automatically generates a reducer that does the caching and it automatically generates react hooks that, , you just say, , use, get Pokemon [00:20:00] query quote Pikachu in a component and it automatically requests the data inserts into the store, selects the data in the component, and gives you like your data and is fetching fields. And it is just so much easier to work with and it handles a lot of both. Simple and advanced use cases built in, So I, I don't have exact usage stats, but I can tell you that a lot of the questions we get these days are about using R T K query, and that's great because it means people aren't having to write all this data fetching code themselves. Noel: Yeah. R k cor is included in. Rtk, so it's like you don't have separate numbers, cuz it just always gets downloaded for everybody. Yeah. Cool. Mark: Yeah, it's RT Query is part of the Redux Toolkit package is just in nested entry points because we have both a vanilla JS version of RTK Query and then the React specific version as well. And then the last piece that's in there is called the Listener Middleware. So , , [00:21:00] people had traditionally used libraries like Saga, , Redux, saga and Redux, observable for writing, , reactive logic. Like when this action is dispatched, go kick off this like sub-process or something. And they work, but they're very heavyweight, conceptually and tricky to use. And so we wanted to have something built in that solved almost all the same use cases. But with a simpler api, smaller bundle size and better type script support. So that came out last year and we've gotten a lot of really good feedback on it. Noel: , so I guess specifically with Query, what advantages does it have over using something like S W R or React Query? Mark: We've had some conversations with the React Query maintainers, , Tanner Lindsays and Dominic Dorf Meister, and we basically cross endorse each other's libraries. So if you're, writing like a Plain React app, you should use R T K query for your data fetching. If you're using Redux in your app, you should be using RTK query for your data fetching. , the point is that either way you're getting a [00:22:00] library that is battle tested, that does all the work for you, and handles all the, the weird edge cases and stuff that you probably wouldn't have thought of yourself, with the listener middleware. Like I said, people have already always used things like sagas and observables for reactive logic, and they work, but they're too powerful. It's using a chainsaw to cut a loaf for bread or whatever weird analogy you want to use it's just too powerful, too complicated. And so we wanted to provide something that did, handled most of those use cases outta the box, but was a lot simpler and easier to work with. Noel: Are those two domains, the ones that you guys felt had the most or were used the most and that's what justifies putting them into? , R T K Mark: Yeah, so like when we're debating like, is this something worth building into R T K? It's a combination of how common is this problem in the redux ecosystem and. What libraries are people writing to deal with this? What other solutions are out there? , a couple examples. We [00:23:00] get a number of folks asking us if we are going to build persistence functionality into T K, saving your state to local storage or wherever. And thus far we've always said no because there's already a fairly popular library called Redux persist, which is basically the de facto standard for doing this stuff. And it's there and it works. And we, we don't need to reinvent that wheel. , there's definitely enough people wanting to do persistence that some solution needs to exist, but we don't feel the need to build that into the core ourselves. there, there are some things that are probably coming in RTK 2.0 on the other hand, where we are trying to solve some of those problems in our own code. Noel: What a perfect segue. Yeah. So tell us what's coming in 2.0. Why? Maybe just start with, why is this 2.0. Mark: Because it's a major version and every library builds up, , cruft and mistakes over time, and you have to go back and fix those things. And that means breaking changes and major versions. , we have a few different goals for 2.0. , one is that we want to try to have [00:24:00] quote unquote correct ES module, common JS packaging , which is both an annoyingly nebulous and seemingly continually changing goal. being able to correctly import redux toolkit under node with ES module flags turned on. Another is we wanna modernize the JavaScript build output. We've always been transpiling our code, so it would work outta the box in i e 11, i e eleven's dead. We want to stop supporting it, and that'll help shrink bundle sizes a little bit. , another is that we have accumulated a number of, APIs or options that we've deprecated. And it's time for those to go away, which is technically breaking changes. , we do have a few new features we're working on, and along with that, we actually converted the Redux core library to type script back in 2019, and then it sat in our master branch for three plus years and never got released. , so it's time for that to actually get published. , and along with that, we are making [00:25:00] some tweaks to the types. In both the core and R T K, , to try to, be a little more, slightly more correct behavior. Noel: Is that Redux like 4.2 to five? Is it is type script in Mark: But yeah. There, there's no, no meaningful functionality changes. , but the difference is we went from JavaScript source code. With a handwritten type definitions, file to type script, source code, and generating the type definitions along with tweaks to those types. Noel: , back to rtk. I saw Alpha one was like beginning of this year. Now you're on five. What's that timeline looking like? What are you looking out for? What are your signals? , Mark: I don't know when it's done. It's done. part, so part of the issue is we don't have a fully defined scope of exactly what will go into 2.0 before we know it's done. , \ , I'm hoping to try to keep it somewhat constrained. , it would be very easy to get caught up in a trap of what's [00:26:00] 2.0. Let's throw more features and more features in there. , if you think about it, most features are new. Like those can go in a minor release. We've got a couple we're putting in partly because , they're ideas that we've had and we've been working on, and they need some of the types changes and the other things we're doing right now. , so they can't go in a 1.9 or in a one point x version. , but strictly speaking, they could also probably have waited until. After 2.0 was out, and then we , add them in like a 2.1 or a 2.2 or something. so I, I don't have a hard timeline. I'm hoping, quote unquote, sooner rather than later. , but I would be nice if we can get this out in, I don't know, hand waving like three, four months instead of a year. Noel: , I wasn't trying to put you on the spot. I was more just curious like how you were feeling, like getting the temperature, like bad enough, stability-wise and bug reports and stuff. Is it feeling pretty good? Are devs having trouble, trying to make the switch for experimentation? Or is it[00:27:00] Mark: The first rule of developing and maintaining a library is it doesn't matter how many alphas and betas and release candidates you put out, basically, no one is gonna try it until you actually publish it live, and then everybody will install it and tell you how broken it is. Happens every time. , there, there have been , a few folks who have tried out some of the Alphas. , but it's been very little feedback so far, which brings up some of the work that I've been doing myself. The whole ES module, common JS thing continues to be the JavaScript community's version of the Python two to three transition. It's long, it's ongoing, and it is just an absolute painful nightmare to deal with. I've got a secondary browser window where I've probably got like 150 tabs on the topic, scrolled away, and. , I've learned a ton over the last few months, and every time I make another tweak, one of the people who knows what they're talking about pops up and tells me that there's something else that I'm doing wrong. Noel: Yeah. Mark: But [00:28:00] it's been stuff like creating a small Redux toolkit example app that just does a counter that test out, create slice, , and two different uses of RTK query. One without React and one with making that into, you know, like a little reusable, a little application. Copy pasting it across multiple different projects. So create React app four, create React app, five, next ve, et cetera, and having those in our repo, installing PR built versions on every push, and testing those out to make sure that they actually compile and run properly. , And then I've actually been able to reuse that across the other redux related repos, like the core or reselect or redux thunk, so that I can test out packaging and, like types changes in those repos as well. And [00:29:00] see if any changes to those libraries appears to break the applications. I also found a tool from one of the TypeScript maintainers called Are the Types Wrong. And it's primarily a website where you give it either a package name inversion or you upload a tarball and it looks at all the package export definitions and tells you do these appear to be correct and here's how type script is interpreting them. And it'll tell you like there, here's a whole bunch of like common errors with, not being able to find the types or mismatched file extensions or whatever. And if you look at the repo for that website, there's a core logic folder. And the website folder and I was able to build a C L I tool that uses the core scans a package, prints out the same table that in the command line that the website shows you, and then turn that into a GitHub action step so that I can scan the package formats every time I make a change. , and I'm hopeful someone can turn that into a real. [00:30:00] GitHub action that would be reusable, but it's like I've been going to all these extra steps just to try to make sure that I'm not accidentally screwing things up. Noel: Yeah. Like you said, I feel like it's super useful to have those kinds of tools like , in this library space where you can like, have a bunch of targets and just have it run every time. Even just if it compiles is probably a pretty good test for you guys most of the time, I would imagine. Mark: So the E s m CJ S thing is what I've probably spent the most time on. , we're also now generating fully modern JavaScript build output syntax. So basically not transpiling any of the JavaScript code. , so no more i e 11. Good rids. we've upgraded the redux cores type script types, for example, , middleware. Used to treat the action parameter as any, and we're now treating it as unknown because it literally could be anything. It could be an action object, it could be a thunk function, it could be a promise. And so we're being stricter. And if you want to interact with it, you really need to do a type check to confirm what you [00:31:00] think it is before you try to access a field on it. = Michelle West Eight, the author of the ER library. , just put out ER 10. , this also drops a bunch of backwards compatible stuff. It drastically improves update performance. , the bundle size is smaller. I was actually able to contribute and update to the build system based on a lot of the work that I'd been doing. , and so the Alphas now depend on Emmert 10 final. So again, smaller bundle size, faster updates. What's not to love? , and we've killed a few different, , bits of deprecated, options and pieces. The biggest one is that create slice dot extra reducers used to accept an object full of action types to listen to. And the problem is that did not give you any TS type safety. It was okay when we first came up with Redux Toolkit and everything was still playing js, but we really want people using type script instead. And so for a couple years [00:32:00] now, we've had this, like Java style builder callback. Syntax. So you know, builder, ad case do a matcher and that works much better with type script. It's basically the same number of lines of code. So we deprecated the object syntax in 1.9 and we've removed it in the alphas for 2.0 and there's even a code mod that tries to help update your code if you wanna run that. . And then the other change at the moment. Is that we just merged an experimental new a p I called combined slices. So the Redux core has always had an a p I called Combined Reducers, and that's where you pass in, your post reducer users reducer comments reducer, and you get the top level state object reducer function. Noel: Yeah. Mark: And the biggest thing here is that. Redux has never had anything built in for lazy loading or code splitting of [00:33:00] logic. There's like a copy paste recipe in our documentation. and there were a couple third party libraries people had done with this, but there was never anything built in. of the way combined Reducers works, you have to keep around references to all the old slice reducer functions. So that you can pass all of them, plus the new one to combine reducers again, then he calls, stored out, replace reducer to swap it out. So we have, a relatively new person who's joined our maintainers group, , has handles Eskimo Joe, and one of the things , he built out, , About a year ago maybe, , lens Weber, the other primary maintainer had put up an issue with a notional pitch for some a combined slices type api, and maybe it would have some support for LA injecting. Slice reducers into it. And so Eskimo Joe tackled that, and in the space of just a few weeks, was able to build out something that appears to, implement what we had drafted out, a [00:34:00] while back. , but the biggest thing is it allows you to pass in like the entire slice objects as parameters, and then it'll automatically combine them using the name fields as the keys of the Noel: Oh, cool. Mark: Um, And then it keeps those around and the reducer that it returns actually has a dot inject function attached to it. And so if I understand this right, you can inject more slices later and it'll add them. And you don't even have to call like store dot replace reducer to make it work. I think, , it also has the ability to generate some selectors. That fall back to the slices initial state if the slice has not been attached to the store yet. ,, there was always like that timing question of I need to inject this reducer, but also my lazy loaded components need [00:35:00] access to that state. And if they try to read the state before the reducer gets injected, then that field is undefined because it hasn't been added yet. And so The idea is that like by having the selector itself do a little bit of a fallback, you at least guarantee you're not gonna see an undefined value there. , Noel: So if, , listeners wanna go check stuff out, where would you recommend they jump in? Would you guys need help, testing stuff in the V2 alpha? Or would you just say, nah, I feel like you're getting your feet wet. Still Mark: I would love to have more feedback. , so the Alphas are all listed on the RTK releases page. , you can install whatever the latest one is by, n p i at readex slash toolkit at Alpha, and it'll, go grab whatever the latest alpha is. Overall the alpha is stable. I mean it's alpha because we're still making a lot of changes. Most of those changes have been around the packaging and the types so far. Like the core of the library is rock solid, and I would expect that most people [00:36:00] could probably just update to the latest alpha and fingers crossed it ought to just work and. The most likely thing that would happen is maybe some of the TS types tweaks around, like custom middleware or a few other cases like that. , but I actually feel very good about the stability of these alphas as a whole. Noel: Nice. Awesome. Awesome. That's a, that's good A note, , as any to end on. Thank you so much for coming on and chatting with me, mark. it's been a pleasure.