You forgot to talk about Redux Toolkit Query / RTK Query. Its a data fetching and caching library that works seamlessly with Redux toolkit. Its basically Redux's answer to React Query. Super useful if you don't want to break out of Redux's patterns while also not having to worry about doing the heavy lifting of caching your own data.
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.
One of the best videos on web dev that talk about a technology: to the point, clear, and explains the why and the hows to someone who is new to the topic. Amazing!
Many times you want the state on the server, which makes react-query a better solution. In your user example the leaf components would send a mutation to the server, and the updates would be handled by react-query's caching mechanisms. But looks cool :)
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.
Wow. I wasn't aware that Redux had resolved so much. I was firmly stuck in seeing it implemented in a project around 2017 or so I think. It seemed incredibly boilerplatey as you say, and complex. I will look back into it again.
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.
Is Redux still relevant in 2023? No. Unless you have a huge app with a lot of client side state like a video editor app, ui design app like figma, etc. In 2023 and beyond just use React Query for all your async server state and React Context or Zustand for the little global state that is left. Redux should be only be considered on VERY specific cases.
I feel like people who vehemently hate on redux at every opportunity only used the old crap syntax (with mapStateToProps and mapDispatchToProps), the new hook solution is much nicer to work with
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,.
I don't even use any other libraries. 👀 I just use React Context + React Query. And these cover almost everything I've ever had to do in my projects. Would wanna know if this isn't the best practice. Why is context never mentioned when talking about state management? Is it not good or there's something else?
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.
Thank you so much for this video. That’s true a lot of things are said around redux but your explanations and point of view are very helpful. Great video, as usual!!!
Can't wait to go freelance and do everything with vanilla JS. I'm so done with this "here's a library that solves a problem caused by another library imported by this library to fix the inherent issues of library XYZ" mess.
Oh man, this is godsent ❤ we're just about to pick a state management lib for our project. I got fed up about redux some years ago because of all that boilerplate, just like you said. Now I'll give it a go again! Thanks so much
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.
I’m one of the folks who thought of redux was too boilerplate-y. Might be worth a look between the slices, thoughtful conventions, and the dev tools. Will give another look on my next project 🙂
Toolkit's types are a bit tricky sometimes. My issue was with createSlice and trying to add type to actions. I wasn't the one who created that slice and just passing by tried to add some type here and there :)
I went all the way tru the journey, old Redux wasn't happy but was able to survive, fell in love with toolkit, then forgot all once I saw Zustand lol (I test in prod heh)
If you mention redux in the reactjs subreddit mark comes out of the nearest bush to tell you about it hahaha. It is such a blessing to have the maintainers so acessible
Matt amazing as always ! I used Redux toolkit, it simplifies state management a lot and it makes the model also clearer, and for me that's one of the most important things when managing state. As for putting all of the state in redux, I don't think it's actually necessary, I would put only the main state, so this forces you to think about how to organize and manage state in your app and that's a necessary thing, if not done would result in difficult to maintain and debug apps.
As always, great video Matt! Tools like redux (w or w/o toolkit) allows you to manage a store that only needs to change locally and does not connect to some external resource like an API, for that you will have to use something like react-query or redux toolkit query, right? If it's the case, what would be the best stack? 1. redux toolkit for local state management + RT query for async state 2. react-query for async and React.context for local 3. a mix of both
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.
I respect Redux as a library, but my personal preference is plain old React Context + useReducer hook. Maybe it's because I'm so used to it I can whip something up real quick, but also I just find it provides everything I need. React-query also works pretty well for server-side state management. I think useReducer is also one of the best hooks in React
Nice video! I also like Redux-Toolkit and appreciate all the efforts that maintainers put into it. But some typescript inside Redux-Toolkit is very tricky, especially type for dispatch that can take actions and need to support different kind of middlewares. May be you can make a video about typescript types that are used in Redux-Toolkit?
@@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.
Redux is an abstraction that can be avoided by rethinking the architecture of the app. Before it was harder but now with signals I think there is no need for redux. I prefer to use even driven programming instead of redux. Instead of dispatching actions just fire your custom even.
Out-of-date examples and training are ruining the ability to effectively search for technical answers. Even StackOverflow is getting clogged up with answers that were good when originally written but are now flat out wrong. It's great to hear a tech communicator mentioned this exasperating problem.
Doesnt the contextApi also makes so all logic from your app can be in one place? Cause you can just add functions to the context itself and so it works basically like redux?
Am I naive for just not needing much client side state in my apps? I have been writing react for 7 years now, and I don't think i've used global state other than a simple Context in nearly 2 years. Maybe this is because Remix handles global state a bit differently. Just let your framework/browser handle all the gnarly state wherever possible. HTTP state? Use your framework (or react query), form state? Use HTML forms and your browser, loading and errors are handled natively. Validation? HTML forms. User authentication , cookies are stateful no?I feel like React develoeprs are on a mission to write as much code as possible sometimes. The best amount of code to write is no code - thats the best lesson i've ever learnt. And its why I haven't picked up Redux or any of its successors in years
The idea that redux was ever boiler-plate heavy wa actually never true for any developer who took a little trouble to reduce it. And I still use the "old" versions.
I personally think Redux is just a fancy lib and nothing more. Everything it offers you can implement in 30 lines of code without all those unusual abstractions. I personally think that keeping everything in one global store is bad idea. Also you don't need to use that special state reactivity everywhere in your app, usually it's just ok to pass things down the tree without extra boilerplate and additional files here and there... I played a lot with Redux, but never adopted it in my real projects... usually I build everything around so called "atoms" with straightforward JS functions, code is simple and easy to reason about
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.
Thanks for the video, I'll give have to give redux another go. I have always found it easier to suffer the prop-passing than to get redux set up for my small projects. Hey Matt, have you ever written a typescript language server plugin? I recently made a video about my attempt... it was hard to find resources, bit of a niche interest.
I like Redux, but I still don't see why it is needed with Context. It's not too difficult to build out a Redux replica using useContext. You can set it up exactly like the old boilerplate, or create a custom hook and get a more tanstack approach. are there things that Redux dos that usecontext doesnt?
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.
That's the exact video that I have been looking for about the new redux! i have been using redux 3 years ago and everyone was saying it was bad and not needed most of the time and they were right kinda, I then stopped coding as it's not my main field and when I came back this year I was confused why is redux everywhere now ? and what is redux toolkit, is redux very popular now ? Thanks for the clarification
Redux is still relevant in 2023 but not how people are thinking about it. Redux toolkit is a lot better then the legacy. But with react query which is far better for web and react native, zustand is great for module federation and light wait stores. But where redux will out live all of these kids is in the desktop kind of apps. ENTER Tauri. Thanks for keeping the lights on.
I neverknow react, but I use redux pattern as my state management choice (ngrx) in angular, iand i like it very much, the nowadays syntax has already much shorter than the older but under the hood still using the pattern, only less boilerplate.
It wasn't so clear to me how the Context API can't replace rtk. In your example I see it being to achieve the same thing. Can someone elaborate on how it doesn't replace rtk. Btw I've been using rtk since it came out and I enjoy it.
With the popularity of other external state management libraries such react Query, which needs no boiler plate what so ever and is being adopted by other technologies such as trpc I still prefer Redux toolkit and Redux toolkit query because it allows to manage both internal and external states but I don't if my reasons are valid.
Unfortunately I couldn't see most of the video because my eyes exploded at 3:09, jk I actually like light mode. I think Redux is amazing. I like using it even for very simple projects where I don't need complex state management and much tree traversing. The thing with React is that managing any state that's not local or goes deeper than 1 component is just messy and not fun to work with - yes, even with hooks. Redux does require some setup if you just want to start using it, and that's gotten some criticisms (or rather it's simply acknowledged as one of its downsides), but even that process has been improved, and most importantly once you do set it up the state management just becomes much more streamlined and the developer UX improves along with it. Redux DevTools is pretty cool too and doesn't force you to look at bright things like Matt does.
You start by explaining that Redux primary purpose is to avoid prop drilling, then you say that it's not its main purpose somehow? The values in your store change when you dispatch pre-defined actions. Ok, how is this different from useContext/useReducer exactly? Single place where all the logic lives? I don't think so. The components will still have the bulk of the application logic and they will interact with the store when(if) needed. I used Redux a lot prior to hooks coming out, and while I wasn't saying "redux is dead" I certainly haven't used it once since useContext/useReducer became available.
Dave Gray's course on RUclips on Redux Toolkit/ RTK Query is the best source for learning latest Redux in react. Promote him if you want the beginners to learn it in modern way.
If "new redux" is such a paradigm shift, then maybe they shouldn't have called it "redux". People already learned what "redux" means. In a way, the maintainers signed up for that burden when they made that choice. Of course, the trade-off is that they have a bazillion weekly downloads to show for their usage statistics.
I don't consider signals to be state management - they help solve the prop drilling problem in a different way to explicit subscriptions. As I say in the video, state management is all about centralizing the logic for how your app changes, not solving prop drilling.
Global state is a mistake. When anything can change anything from anywhere.. It's like going back to global variables. So hard to understand and debug. React context is a much more elegant solution for the few things that actually need to be shared.
Redux was never bad for me. Where things fall over is the implementation. Redux gets put down because devs do a bad job of doing redux properly and devs are lazy.
I prefer the older style of redux because redux toolkit is too much of an abstraction imo. In the old style, the reducer logic is all laid out plain as day, and the boilerplate necessary to set it up is what makes it so dependable, customizable, and debuggable.
Zustand can do async and be configured to use redux dev tools. Theres no reason to use redux anymore. Redux-slice is even worse in terms of boilerplate than the OG
Redux is the most unclear and overcomlicated manager. Just trash can of code. I'm so happy since I stopped using it. There are a lot of better and much better managers, that it is time to forget it as nightmare
Chucking everything in one place to avoid using your brain isn't a good reason to use Redux. Global state should be for state that actually needs to be global.
why would anyone use anything other than Jotai, if he cares about performance or nanostores if he wants the simplest and most flexibility!!? stop shooting yourselves in the foot
"Should you still be using Redux in 2023?" - no. For goodness ssake, no. There are significantly better alternatives. Context. Zustand. More. There's only one reason to use Redux, you need to know it to work on old stuff.
I've been writing Vue for a long time. I have had a good React experience lately. I think redux is one of the worst tools in the ecosystem. Vuex is over, it's Pinia now. The time is coming for redux (for React applications). Zustand or jotai may win the fight.
Highly disagree. Redux is pointless in a React application. Context solves all the problems Redux does without adding anything unnecessary. You can put whatever you want inside Context. You implied in your comparison that Context is for avoiding prop drilling but there's nothing stopping you from putting all the state management logic into Context. You could even put everything in a single Context and now you have Redux without Redux. People pulling in pointless dependencies instead of just learning the APIs they already have access to drives me insane.
Context has a lot of perf issues that you should know assuming you actually took the study its internals Tools like Zustand solve that problem, and yeah, it's a breath of fresh air compared to Redux boilerplatekit Tbh if I never encountered those inherent perf issues with context, my rant would definitely have been similar to your
![[Limbus Company - Teaser] Season5 - Oblivion](http://i.ytimg.com/vi/8anKuEeZLeI/mqdefault.jpg)
You forgot to talk about Redux Toolkit Query / RTK Query.
Its a data fetching and caching library that works seamlessly with Redux toolkit. Its basically Redux's answer to React Query. Super useful if you don't want to break out of Redux's patterns while also not having to worry about doing the heavy lifting of caching your own data.
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.
One of the best videos on web dev that talk about a technology: to the point, clear, and explains the why and the hows to someone who is new to the topic. Amazing!
Many times you want the state on the server, which makes react-query a better solution. In your user example the leaf components would send a mutation to the server, and the updates would be handled by react-query's caching mechanisms.
But looks cool :)
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?
Zustand all the way baby. Gotta go fast!
Wow. I wasn't aware that Redux had resolved so much. I was firmly stuck in seeing it implemented in a project around 2017 or so I think. It seemed incredibly boilerplatey as you say, and complex. I will look back into it again.
I'm using Redux Toolkit in my React Native app, it was a bit clunky to get set up and used to but I'm happy with it and it's modularity so far.
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.
Sounds like modern React's-redux and Vue's-Pinia are pretty much drinking from the same special sauce..
Is Redux still relevant in 2023?
No. Unless you have a huge app with a lot of client side state like a video editor app, ui design app like figma, etc.
In 2023 and beyond just use React Query for all your async server state and React Context or Zustand for the little global state that is left.
Redux should be only be considered on VERY specific cases.
I feel like people who vehemently hate on redux at every opportunity only used the old crap syntax (with mapStateToProps and mapDispatchToProps), the new hook solution is much nicer to work with
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,.
I don't even use any other libraries. 👀 I just use React Context + React Query. And these cover almost everything I've ever had to do in my projects. Would wanna know if this isn't the best practice. Why is context never mentioned when talking about state management? Is it not good or there's something else?
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.
sure, context doesn't replace redux, but what about context + useReducer?
MobX State Tree is often nicer to use imo.
But i must say, the way svelte handles this with stores is far less boilerplatey
Thank you so much for this video. That’s true a lot of things are said around redux but your explanations and point of view are very helpful. Great video, as usual!!!
These explanation diagrams look really neat. Which tool is used to create them ?
Let me know if you found the answer to your question, thanks 😊
Omg, someone said the same things I've been saying this whole time!
Can't wait to go freelance and do everything with vanilla JS. I'm so done with this "here's a library that solves a problem caused by another library imported by this library to fix the inherent issues of library XYZ" mess.
Unfortunately I'm the same but no one will want that
Oh man, this is godsent ❤ we're just about to pick a state management lib for our project. I got fed up about redux some years ago because of all that boilerplate, just like you said. Now I'll give it a go again! Thanks so much
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.
Rtk query only needs infinite query api to be on par with tanstack swr apollo and everything inbetween
I’m one of the folks who thought of redux was too boilerplate-y. Might be worth a look between the slices, thoughtful conventions, and the dev tools. Will give another look on my next project 🙂
Very good as always. Btw I appreciate your care about content warning at 03:07.
Toolkit's types are a bit tricky sometimes. My issue was with createSlice and trying to add type to actions. I wasn't the one who created that slice and just passing by tried to add some type here and there :)
I went all the way tru the journey, old Redux wasn't happy but was able to survive, fell in love with toolkit, then forgot all once I saw Zustand lol
(I test in prod heh)
If you mention redux in the reactjs subreddit mark comes out of the nearest bush to tell you about it hahaha. It is such a blessing to have the maintainers so acessible
Matt amazing as always ! I used Redux toolkit, it simplifies state management a lot and it makes the model also clearer, and for me that's one of the most important things when managing state. As for putting all of the state in redux, I don't think it's actually necessary, I would put only the main state, so this forces you to think about how to organize and manage state in your app and that's a necessary thing, if not done would result in difficult to maintain and debug apps.
As always, great video Matt!
Tools like redux (w or w/o toolkit) allows you to manage a store that only needs to change locally and does not connect to some external resource like an API, for that you will have to use something like react-query or redux toolkit query, right?
If it's the case, what would be the best stack?
1. redux toolkit for local state management + RT query for async state
2. react-query for async and React.context for local
3. a mix of both
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.
I respect Redux as a library, but my personal preference is plain old React Context + useReducer hook. Maybe it's because I'm so used to it I can whip something up real quick, but also I just find it provides everything I need. React-query also works pretty well for server-side state management.
I think useReducer is also one of the best hooks in React
Matt, amazing video! Can we still use Redux Toolkit if we build our React app with some other builder different than CRA?
Yes! Redux-toolkit is just JavaScript, so it'll work anywhere JavaScript runs.
@@mattpocockuk Amazing
OG Redux with all the actions, selectors and reducers with massive switch statements make me want to throw up
3:15 thank you so much
Nice video! I also like Redux-Toolkit and appreciate all the efforts that maintainers put into it.
But some typescript inside Redux-Toolkit is very tricky, especially type for dispatch that can take actions and need to support different kind of middlewares. May be you can make a video about typescript types that are used in Redux-Toolkit?
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.
Redux is an abstraction that can be avoided by rethinking the architecture of the app. Before it was harder but now with signals I think there is no need for redux. I prefer to use even driven programming instead of redux. Instead of dispatching actions just fire your custom even.
Nice one Matt!
Out-of-date examples and training are ruining the ability to effectively search for technical answers. Even StackOverflow is getting clogged up with answers that were good when originally written but are now flat out wrong. It's great to hear a tech communicator mentioned this exasperating problem.
I like this type of video Matt, thanks
thanks for the content
it is perfect and we looking forward to see more contents about redux and other libraries
Doesnt the contextApi also makes so all logic from your app can be in one place? Cause you can just add functions to the context itself and so it works basically like redux?
Am I naive for just not needing much client side state in my apps? I have been writing react for 7 years now, and I don't think i've used global state other than a simple Context in nearly 2 years. Maybe this is because Remix handles global state a bit differently. Just let your framework/browser handle all the gnarly state wherever possible. HTTP state? Use your framework (or react query), form state? Use HTML forms and your browser, loading and errors are handled natively. Validation? HTML forms. User authentication , cookies are stateful no?I feel like React develoeprs are on a mission to write as much code as possible sometimes. The best amount of code to write is no code - thats the best lesson i've ever learnt. And its why I haven't picked up Redux or any of its successors in years
The idea that redux was ever boiler-plate heavy wa actually never true for any developer who took a little trouble to reduce it. And I still use the "old" versions.
I personally think Redux is just a fancy lib and nothing more. Everything it offers you can implement in 30 lines of code without all those unusual abstractions. I personally think that keeping everything in one global store is bad idea. Also you don't need to use that special state reactivity everywhere in your app, usually it's just ok to pass things down the tree without extra boilerplate and additional files here and there... I played a lot with Redux, but never adopted it in my real projects... usually I build everything around so called "atoms" with straightforward JS functions, code is simple and easy to reason about
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.
Thanks for the video, I'll give have to give redux another go. I have always found it easier to suffer the prop-passing than to get redux set up for my small projects.
Hey Matt, have you ever written a typescript language server plugin? I recently made a video about my attempt... it was hard to find resources, bit of a niche interest.
I like Redux, but I still don't see why it is needed with Context. It's not too difficult to build out a Redux replica using useContext. You can set it up exactly like the old boilerplate, or create a custom hook and get a more tanstack approach.
are there things that Redux dos that usecontext doesnt?
I haven't used redux toolkit, but regarding the store, what prevents me from creating one similar to redux using only Context?
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.
What's a good, up to date rtk query course with a meaningful app, larger than a to-do example?
That's the exact video that I have been looking for about the new redux!
i have been using redux 3 years ago and everyone was saying it was bad and not needed most of the time and they were right kinda, I then stopped coding as it's not my main field and when I came back this year I was confused why is redux everywhere now ? and what is redux toolkit, is redux very popular now ?
Thanks for the clarification
what you think about Mobx?
Redux is still relevant in 2023 but not how people are thinking about it. Redux toolkit is a lot better then the legacy. But with react query which is far better for web and react native, zustand is great for module federation and light wait stores. But where redux will out live all of these kids is in the desktop kind of apps. ENTER Tauri. Thanks for keeping the lights on.
I neverknow react, but I use redux pattern as my state management choice (ngrx) in angular, iand i like it very much, the nowadays syntax has already much shorter than the older but under the hood still using the pattern, only less boilerplate.
What about @legend/state 3.0.0-alpha w/ observables to boot? Looks way better than Redux!
It wasn't so clear to me how the Context API can't replace rtk. In your example I see it being to achieve the same thing. Can someone elaborate on how it doesn't replace rtk.
Btw I've been using rtk since it came out and I enjoy it.
What do you think of coding your own store in typescript from scratch, which you can subscribe to changes with callback functions or send changes
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.
May we have a rtk-query with typescript tutorial?
With the popularity of other external state management libraries such react Query, which needs no boiler plate what so ever and is being adopted by other technologies such as trpc I still prefer Redux toolkit and Redux toolkit query because it allows to manage both internal and external states but I don't if my reasons are valid.
Unfortunately I couldn't see most of the video because my eyes exploded at 3:09, jk I actually like light mode.
I think Redux is amazing. I like using it even for very simple projects where I don't need complex state management and much tree traversing. The thing with React is that managing any state that's not local or goes deeper than 1 component is just messy and not fun to work with - yes, even with hooks. Redux does require some setup if you just want to start using it, and that's gotten some criticisms (or rather it's simply acknowledged as one of its downsides), but even that process has been improved, and most importantly once you do set it up the state management just becomes much more streamlined and the developer UX improves along with it. Redux DevTools is pretty cool too and doesn't force you to look at bright things like Matt does.
You start by explaining that Redux primary purpose is to avoid prop drilling, then you say that it's not its main purpose somehow? The values in your store change when you dispatch pre-defined actions. Ok, how is this different from useContext/useReducer exactly? Single place where all the logic lives? I don't think so. The components will still have the bulk of the application logic and they will interact with the store when(if) needed.
I used Redux a lot prior to hooks coming out, and while I wasn't saying "redux is dead" I certainly haven't used it once since useContext/useReducer became available.
Can you make a complete typescript course? A beginner to advanced course....
Yes! totaltypescript.com has a free beginners course, and a huge industry-level advanced course.
Great video and a great guy
Dave Gray's course on RUclips on Redux Toolkit/ RTK Query is the best source for learning latest Redux in react. Promote him if you want the beginners to learn it in modern way.
wait, isn't it what svelte stores do natively ?
Just use jotai and make everything atomic
Really would love you to compare with mobx
So yes, but also no, unless it's already being used, then yes?
If it's there, yes.
If it's not there, maybe.
The main problem with redux is it's still bloated enough to feel like overkill compared to new gen tooling
Very disappointed to hear that, you should mention downsides too
If "new redux" is such a paradigm shift, then maybe they shouldn't have called it "redux". People already learned what "redux" means. In a way, the maintainers signed up for that burden when they made that choice. Of course, the trade-off is that they have a bazillion weekly downloads to show for their usage statistics.
Why to me redux seems like a tool that solves problem that should't even exist. Is redux just a disquised singleton?
Why are they complicating frontend just to show off?
I haven't touched redux since 2019. And yes, my dislike for redux comes from that era. The modern redux syntax looks a lot like zustand
As a VueX user, I feel left out and all lonely. 😢
Did Vue replace vuex with pinia
No, market effector more... This marketing of this tool is so... so hyped
talk more about redux :)
What about useSignals? If you use signals, Does it not solve the problem of state management?
I don't consider signals to be state management - they help solve the prop drilling problem in a different way to explicit subscriptions.
As I say in the video, state management is all about centralizing the logic for how your app changes, not solving prop drilling.
👍
Global state is a mistake. When anything can change anything from anywhere.. It's like going back to global variables. So hard to understand and debug. React context is a much more elegant solution for the few things that actually need to be shared.
Redux was never bad for me. Where things fall over is the implementation. Redux gets put down because devs do a bad job of doing redux properly and devs are lazy.
Redux is really confusing for me, I’m still learning to useState and not worrying about prop-drilling haha
I prefer the older style of redux because redux toolkit is too much of an abstraction imo. In the old style, the reducer logic is all laid out plain as day, and the boilerplate necessary to set it up is what makes it so dependable, customizable, and debuggable.
Zustand🎉
I always face issues to test components that has children using Redux =/
Zustand can do async and be configured to use redux dev tools. Theres no reason to use redux anymore.
Redux-slice is even worse in terms of boilerplate than the OG
nice
Redux is the most unclear and overcomlicated manager. Just trash can of code. I'm so happy since I stopped using it. There are a lot of better and much better managers, that it is time to forget it as nightmare
zustand is just better in every way
Chucking everything in one place to avoid using your brain isn't a good reason to use Redux.
Global state should be for state that actually needs to be global.
Maybe a weird question, but what tool are you using to draw those graphs and what font are you using? I really like both of them :) @Matt Pocock
I would like to know that too
why would anyone use anything other than Jotai, if he cares about performance or nanostores if he wants the simplest and most flexibility!!? stop shooting yourselves in the foot
zustand
"Should you still be using Redux in 2023?" - no. For goodness ssake, no. There are significantly better alternatives. Context. Zustand. More. There's only one reason to use Redux, you need to know it to work on old stuff.
nice to pay respect to the OG-s
it works, maintainers are great, it's just boring for me :P
If you can't stand redux or you fail to see its value and how similar RTK and Zustand are, you need to revisit the Design Patterns books.
No. Redux encourages bad design practices. "Just throw it in the store" NO!
No, due to its terrible async support.
reduce toolkit makes redux so ez that no need for replace
I've been writing Vue for a long time. I have had a good React experience lately. I think redux is one of the worst tools in the ecosystem. Vuex is over, it's Pinia now. The time is coming for redux (for React applications). Zustand or jotai may win the fight.
Mobx is way better than redux but nobody talks about it for some reason.
no
RIP redux. Glad its finally "fallen out of the conversation" - for good reason. what a POS
The pronunciation of Zustand way WAY of haha...
All of these problems can be solved by using svelte XD
Svelte will not give you a job
Highly disagree. Redux is pointless in a React application. Context solves all the problems Redux does without adding anything unnecessary. You can put whatever you want inside Context. You implied in your comparison that Context is for avoiding prop drilling but there's nothing stopping you from putting all the state management logic into Context. You could even put everything in a single Context and now you have Redux without Redux.
People pulling in pointless dependencies instead of just learning the APIs they already have access to drives me insane.
Context has a lot of perf issues that you should know assuming you actually took the study its internals
Tools like Zustand solve that problem, and yeah, it's a breath of fresh air compared to Redux boilerplatekit
Tbh if I never encountered those inherent perf issues with context, my rant would definitely have been similar to your
Redux is trash
redux > useReducer