I had a section on this but deleted it for brevity! Let me fill in here: react-query has solved a lot of the problems people _used_ to think of as state management - managing the results of fetching data and updating it. A lot of apps that used to use Redux for their 'server state' switched over to react-query. I think this is a good change - using the right abstraction is usually better. And react-query is now Redux's only real competition on npmtrends - around 3m downloads/week. The fact that redux itself has a first-class abstraction for data fetching is superb, and massively benefits those that use Redux toolkit.

My _only_ gripe having used RTK Query, is that it's very hard to split out things into their own domains/packages without loosing type safety. The issue is really that if you rely on things like cache invalidation and optimistic updates, you have to manually add types to everything. It has the same issues tRPC had before v10 where splitting things out could break the type inference. I am not sure of a way to improve this, though, because that is the tradeoff you have to deal with when you're using a tightly integrated that relies on passing types throughout.

Is there a case to be made for using react-query for caching data from a database to improve load times / optimistic ui, but redux toolkit for ui state? Or does that feel like too much and I should focus my educational efforts on RTK Query if I already know I'm going to use redux? Thanks!

@@mattpocockuk For sure, react-query is love. For new projects react-query is my goto for fetching/caching and redux for monolithic local state management (if any) My point of mentioning RTKQ was to highlight the fact that Redux maintainers still care about their ecosystem and its refreshing to see 😄

​@@TeaganAtwater You can, but you gain so much more from just using RTK Query if you already use RTK. In the end it just provides a middleware to connect the state with your store. You could write one for React Query as well, but it wouldn't benefit you much.

Redux is great, but the learning curve is steep and also react-query took most of the work out of it, so you would mostly need redux in a place like having cart items locally. Still having that amount of code for such thing, I'd go for zustand or jotail unless the whole codebase uses redux.

@@karim6514 You didn't watch the video, did ya?

Do consider why you need state management. Are you only going to store cached data and modify that data? The boilerplate of redux is still to big of a con and you should use tanstack-query. You have a lot of shared UI STATE (not server data state). Then redux is good pick.

Hey, I want to say that it will be difficult in starting but keep learning it and make project with it and slowly and slowly you will be comfortable with it. All the best.

redux-toolkit does contain some tools for handling async state, including a bespoke lib for fetching data like react-query. So the idea is that you could go all-in on redux/redux-toolkit.

Ideally your tests should just interact with the UI and not have any knowledge of the underlying state management library - aside from rendering the providers.

@@robsmith1184 absolutely but your error could be redux specific or error while integrating with the UI. When you are using redux it's not only like state -> UI it's states -> reducer -> store -> UI those are like complex winding of electric wires for complex states....

Much simpler to test. Action creators and reducers are pure functions, for starters

@@victorlongon Ideally your tests should just interact with the UI and not have any knowledge of the underlying state management library - aside from rendering the providers. If you are testing reducers and action creators in isolation then you're testing implementation details.

State management isn't a "simple thing" at all. Especially in React you want to prevent unnecessary re-renders and side-effects. I've been in plenty of teams who thought they could use the context API for state management, and that's just wrong. Tools like Redux take a lot of complexities out of your hands :)

Hi I was one of these people until just now. I tried getting into redux in 2018 and I got spooked. Never went back, and never thought I would ever need to look into it again until I decided to hear what Matt had to say about it

Hi, I *am* one of these people. Maybe I've just been working in some really bad projects or something, but I've never experienced a situation where I was happy to have redux, even after hooks. Every project I've inherited just throws every possible bit of data into redux, and this means that in order to keep things consistent, I must put everything in Redux too, or face the wrath of code review. If I need some data in my non-redux application, I can just useState and useEffect to get and store the data. If I need it to stick around after the component is gone, I can use a context. In a redux application, I need to make an action to trigger the data to be loaded, an action for when it's successfully loaded, an action for when there was a network error, a saga to load the data, add the data to my redux state, create reducers for the different actions,.

Hi, I'm one of the Redux maintainers. Can you give an example of a TS / middleware scenario that you're talking about having trouble with?

@@markerikson3383 Hello! I was talking about typings that redux(toolkit) uses itself. Lets take a simple counter-ts example from redux repo and look at the useAppDispatch type: function useAppDispatch(): [{} extends {thunk: {extraArgument: infer E}} ? ThunkMiddleware : ThunkMiddleware] extends MiddlewareArray ? ExtractDispatchFromMiddlewareTuple : ([{} extends {thunk: {extraArgument: infer E}} ? ThunkMiddleware : ThunkMiddleware] extends ReadonlyArray ? ExtractDispatchFromMiddlewareTuple : never) & Dispatch How can I understand all this? And it looks like even such tricky type does allow to dispatch something like this: onClick={() => dispatch({type: 'garbage'})} which is not expected by any reducer. So it seems that statically checking actions that are dispatched is not possible.

@@markerikson3383 I wish politicians in my country were as approachable as you. Thank you for your contributions to the Redux library.

Let me know if you found the answer to your question, thanks 😊

Yes! Redux-toolkit is just JavaScript, so it'll work anywhere JavaScript runs.

@@mattpocockuk Amazing

I do the same. Learnt it from Pedro tech

I would suggest you to use state management Library over react context..... Because context will rerender every child components that uses it whenever value changes . So if you're using context at root level.... You're basically rerendering everything. And that's last thing you want in react.

Zustand is like a global useReducer, jotai is like a global useState, both of them are designed to be minimal and light-weight in their own design and solve a specific problem. Redux on the other hand is a global useReducer and useState at the same time, which makes it extremely boilerplaty, but can be used to solve all problems that you have with state management in react. If you’re experienced enough, I recommend using zustand or jotai as you’re able to address specific problems that you have with state management. Otherwise, try out redux, you might switch in the future but it’s a good starting line

Thanks. I wish youtube would notify me of replies. I just had to come check this thread manually

If you opt into Redux, you get a lot of support you wouldn't get from a hand-rolled framework, especially on the docs side.

TLDraw!

Nothing! As mentioned in the video.

I mean, you mention that the real advantages of redux are having a single place/store, testable, clean, with action pattern, but I feel like you can easily reproduce this with Context

​@@raphaelqueiroz3105 Be careful of the performance implications of rerendering with context. There are ways to make it more performant by using a pub/sub pattern to allow your components to subscribe to only a piece of the state, and not update when the rest of the context updates. It's not hard, but just something to keep in mind, since context can lead to performance issues if used without consideration.

Yes! totaltypescript.com has a free beginners course, and a huge industry-level advanced course.

Hi, I'm a Redux maintainer (and also the person who chose the name `extraReducers` in the first place :) ). Anything specific you feel is "wonky" about that?

@@markerikson3383 It feels like an afterthought, like it should've been part of `reducers` ... It won't create action creators I suppose, but it's like, what's next if you have more sidecases? `superExtraReducers` and `oopsIforgotReducers`? ;) I jest, but I feel it should've just been part of `reducers` or be called differently. That said, I still prefer the "old way" of doing Redux instead of RTK for my own personal projects. I dislike code with too much magic going on. RTK requires a developer to really know and understand Redux/RTK whereas the old flow felt much more like very transparent vanilla JS. Thunks with optionally using Reselect was a breath of fresh air, to me, I felt like I was perfectly in control. The only downside was boilerplate code being repeated. But with Copilot suggesting 90% of my boilerplate code anyway, that's no longer an issue. For work projects I always use RTK because I know I'm a minority.

@@mahadevovnl Heh. I'll agree that the name `extraReducers` isn't the most brilliant name idea in the world :) The key differnce is: - `createSlice.reducers` is for defining "reducers and actions that are _part_ of this slice". Every field inside of `reducers` will result in a corresponding action creator by that name being generated. - `createSlice.extraReducers` is for handling actions that were defined _outside_ of the slice. That includes actions generated by `createAsyncThunk`, by other `createSlice` calls, or anywhere else in the app. So, they each serve a different and important purpose. FWIW, `extraReducers` _is_ a very intentional part of `createSlice`, and _not_ an afterthought. In fact, I spent time coming up with that part of `createSlice` before RTK 1.0 _specifically_ to address the "handle other actions" use case before I was ready to call RTK 1.0 done. I'll also emphasize that we do really, _really_ want people using RTK, and especially `configureStore` and `createSlice`. They result in code that is smaller and easier to maintain, and eliminate the most common causes of Redux app bugs like accidental mutations: - redux.js.org/introduction/why-rtk-is-redux-today - redux.js.org/usage/migrating-to-modern-redux

"State should be as deep in the tree as it can be. If you're trying to understand a subtree, it's not intuitive to view some global store, where the functionality you're trying to inspect, gets mangled with a bunch of other (unrelated) functionality." the thing is in the end you can either store everything globally or have a mixture. Everything globally is perfectly fine with redux, however I think a mixture is even better. You can't avoid it even without redux

@Bestirsen well, Context forces rerenders across every component that lies inside the Context Provider. This alone (esp. if you are using high velocity and/or big states) is worth the price of admission of using a state management library.

@@PhilipAlexanderHassialis "Context forces rerenders across every component that lies inside the Context Provider" -- as far as I know this is not true. React re-renders any component that subscribes to that context (e.g. uses useContext() hook) and skips re-rendering other components in the tree that don't subscribe. Of course if a component is a child of a component that subscribes to Context it will get re-rendered, but saying "every component re-renders" is false.

@@rand0mtv660 Not thats 100% correct. UseContext has no reactivity. Every child under the context provider that gets changed gets rerendered. Context is reacts dependency injection system and not a statemanagement solution.

@@PhilipAlexanderHassialis I hear this all the time - and i always say the same thing. Will you ever notice this performance hit? No. But do you know what you will notice? The gnarly redux code you have brought in to "fix" this re-reender problem. Optimise for low cognitive load, then look for performance gains. And I guarantee you - your web app's performance issues will not be caused by rendering.

@@danielcooke3243 Tsk tsk. Depends on the velocity and surface area of your state. Try doing something really *BIG* with context. E.g. a frontend for an ERP solution where multiple components across multiple parts of the hierarchy need to be aware of certain partial parts of the same data. Redux is not made for hello-world apps or websites and "web apps". It's made for applications.

Yeah, I started projects at work using Redux toolkit a year and a half ago. Then I switched them to zustand a few months ago. It feels like we reduced the amount of boilerplate by another 30%, and is also a bit easier/more concise to use (especially when it comes to actions, you can forget about dispatch etc.). It feels like it has less layers/transformations between the idea of what you want to do in your head, and the code you need to type to do it. And for me THIS is the most important aspect : reducing the layers between what you have in your head and what you need to type to accomplish it. Jotai is even simpler and can be enough for anything simple. It's literally "globally available useState's".

Zustand is superb

Also zustand have less bundle size, zustand is amazing.

I feel like "the best tool for the job" argument is very often clashing with the "don't optimize prematurely" argument. There are lots of tools that can make life a whole lot easier for you even if they're an overkill for your project, and in the end the users will not notice a meaningful difference. And if they can't see a difference, then what does it matter if the tool is an overkill? Today's browsers are so fast and we have so much computing power that it rarely ever matters what tool you use for the job, really.

I would like to know that too

Care to expand on that? Have you used @redux/toolkit?

@@mattpocockuk You mentioned in this video the issue of boilerplate, for me it's really a pain, and it's not only a normal boilerplate, it's a set of ambiguous functions, Reducers and hooks. I love simple things, and I don't think that you need all this tooling and coding in order to implement a simple global app state management. And yes, I've used redux-toolkit, I'm actually talking about it, and thanks God I didn't use the old combination of 5 packages. Also thank you very much for your content, I really love how you speak and explain TS. keep it up bro.

@@BeFourCM ​ 1000% agree with you. I hate React, I really hate it and I love Angular, but didn't mentioned that at first because I don't want people to judge me and say that my opinion is biased. Definitely not biased, I would rather go with Remix or Astor or even Vanilla JS rather than React. React allows you to write anything anywhere, and devs usually (specially the new ones) do take this advantage and create a hell of an app. I have been assigned a task to move a marketplace app from React to Next.js. IT WAS HELL! I ended up move the app without using any state management tool out there, I created my own state management code using Event Listeners. I think React has created a swamp around it.

Chiming in to say Zustand has changed the world for me. What a great and simple library. I first learnt Redux after I got thrown in to take over a React app that another company had made, and it was incredibly confusing. I had a hard time understanding why so much boilerplate was needed. I've converted it all to Zustand, and it is a JOY to work with.

If i need global state, zustand solves it, It works with redux toolkit

I had a project where it was appropriate to simply have a in-memory store on the server and I just wrote a reducer and a simple store. No framework. It worked great.

Like a meteor to the dinosaurs

​@@mattpocockuk thanks :)

If it's there, yes. If it's not there, maybe.

Did Vue replace vuex with pinia