Should you still be using Redux in 2023?
Вставка
- Опубліковано 10 лип 2024
- Redux is still a massive force in the web development industry, and it's not going anywhere. It's got a pair of extraordinary maintainers, Mark and Lenz, a huge ecosystem of plugins and one of the best documentation sites out there.
00:00 Intro
00:29 How does Redux work?
01:00 Actions
01:49 Subscriptions
02:22 One store
02:38 Slices
03:02 Popularity
03:31 Context API !== Redux
04:43 Evolution
05:41 Legacy Redux
06:35 Would I use it?
Mark: / acemarke
Lenz: / phry
Become a TypeScript Wizard with my free beginners TypeScript Course:
www.totaltypescript.com/tutor...
Follow Matt on Twitter
/ mattpocockuk
Join the Discord:
mattpocock.com/discord
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!
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.
just watched like 4 straight videos from you and i'm pretty sure my neck hurts from continuous nodding in agreement. you always have great takes
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!!!
Love the thumbnail lol, amazing vid, thanks as always Matt
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 just came across your channel and i have to say good job explaining sir and you have won yourself a subscriber
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?
Great channel and how clam your explaining me great 👍
Nice one Matt!
I like this type of video Matt, thanks
Very good as always. Btw I appreciate your care about content warning at 03:07.
thanks for the content
it is perfect and we looking forward to see more contents about redux and other libraries
good video, straight to the point!
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.
Zustand all the way baby. Gotta go fast!
Sounds like modern React's-redux and Vue's-Pinia are pretty much drinking from the same special sauce..
sure, context doesn't replace redux, but what about context + useReducer?
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.
Many people finds react-query with zustand or jotai a good replacement of redux.Yes redux is hard to setup but as your app grows , the structure of redux will make testing a lot easier
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....
Great insight, I used and taught both Redux and Redux Toolkit, I still feel like for beginners, It’s bit confusing but I always start with the importance of keeping one source for truth in you app and I show them examples of how bad things can go if you don’t have that. I feel like people want understand WHY, Why is it so boilerplaty!
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.
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 :)
Great video, thanks so much for the discussion around its legacy and the biases coming from its years of use. Plain redux IS a pain to use, and most apps will only need Jotai or Zustand, but if your app has enough complexity to warrant the redux pattern, redux toolkit is an absolute pleasure to use.
It always annoys me to see ignorant people calling redux "dead" when it's still very much alive...
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
Great video and a great guy
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.
it just cleared my perspective of whats actually going on, thanks mate
I am using redux-toolkit & also rtk-query now. Its pretty good. I want to know can we compare this rtk combo with react-query & zuztand.
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.
Using libraries for such simple things as managing state always kept me away from using them. I always wrote my own classes for that and used dependency injection to populate them through the component tree.
I must admit that I got a strong java background and started with angular in the frontend, moving slowly to typescript, expressjs, nestjs and vue / react as my techstack of choice.
Unfortunately I still do not get the benefits from using a library such as redux over simple stateful objects (except for debugging purposes using devtools).
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, would be good to hear your opinion on JSDoc vs TS question flying around. Thank you.
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 🙂
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?
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 😊
Ok you have intrigued me - I'm willing to consider using redux. Why is it better than react query or zustand?
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,.
Does React not have built in stores and contexts? I'm only familiar with Svelte.
What's a good, up to date rtk query course with a meaningful app, larger than a to-do example?
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 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
Rtk query only needs infinite query api to be on par with tanstack swr apollo and everything inbetween
May we have a rtk-query with typescript tutorial?
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.
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.
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.
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
what you think about Mobx?
Eager to try out redux, but I'm also curious about zustand and jotai. Is redux capable of doing more than zustand?
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
What are you using for these diagrams? Doesn't look like Excalidraw. Balsamiq?
TLDraw!
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.
I might be stupid and I must confess I haven’t used redux, but don’t react contexts solve the same problem, sort of?
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.
Redux seems like a nice library and it is probably pretty mandatory when you're using ReactJs. We are however using Angular for our frontend development and I do not really see the added value of adding Redux into the mix.
Omg, someone said the same things I've been saying this whole time!
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.
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.
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 like redux.but i much prefer recoil js. i pushed a massive production app using early beta version of recoiljs just to make my life harder (sending camera video stream to canvas and from there to p2p connection.all using recoiljs). that's when i knew recoil is the library for me.easy fast and cute.i love it.
Really would love you to compare with mobx
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.
can you try recoil? looks much simpler then redux
MobX State Tree is often nicer to use imo.
But i must say, the way svelte handles this with stores is far less boilerplatey
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)
wait, isn't it what svelte stores do natively ?
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.
Imo the svelte store is a lot cleaner and simpler, I believe this paradigm will get more adaption then redux style stores
OG Redux with all the actions, selectors and reducers with massive switch statements make me want to throw up
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.
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.
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.
Talk about Redux vs Jotai (and why Jotai is better for functional programming)
I'm going to have to disagree with you on this one Matt. For server-state react-query/tanstak-query will do a great job, then for global UI state you have better, less boilerplate solutions such as zustand, recoil, jotai, etc :)
Now I understand that knowing about redux is important because a lot of apps are built with it. But starting a new project today, I will avoid redux.
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.
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.
What about @legend/state 3.0.0-alpha w/ observables to boot? Looks way better than Redux!
Zustand + React Query
nice
Don't like 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. You can split actions and reducers in the file system, which can help. But anytime I've had to debug something in redux, I find myself navigating through many files just trying to understand the data flow. Redux is also hard to eradicate from a project, since it tends to permeate everything you do. I can't say much about toolkit, but it does seem to be an improvement.
"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
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
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.
hi can you do a video about ai and how it impact swe ?
Like a meteor to the dinosaurs
@@mattpocockuk thanks :)
👍
My opinion might be unpopular, but for me I think Redux is the most awful tool I've used in the JS ecosystem.
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
Context is definitely NOT replacament for Redux. I am in project where Context was used as replacement of proper state management, and it is not a fun experience. Not having single "store" with middleware support meant that you had bunch of providers all over the place, and when you have some random contexts integrate with each other it's complete nightmare to debug. Context also doesn't have selectors, they don't have browser extensions for debugging actions etc.
Just use jotai and make everything atomic
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
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.
Years ago, I had to code for IE8. A terrible experience to be sure, but at least I still had Redux, because its core was a pile of mere functions. I hope whatever corporation needed that LMS content has since gotten rid of the need for that old browser.
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.
I always face issues to test components that has children using Redux =/
So yes, but also no, unless it's already being used, then yes?
If it's there, yes.
If it's not there, maybe.
Pretty sure the React team themselves recommend hooks and react-query over Redux these days.
For the vast majority, those are more than sufficient. Not saying Redux doesn’t have its place, but that place clearly isn’t “in every serious React application” like it was a few years ago.
Dave Gray's course on UA-cam 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.
Although I haven't actually used Redux Toolkit, it just seems to me that React has all the state management tools needed for most apps with useReducer + useContext etc.. If you want junior developers to learn React faster and get closer to React's native API:s it seems to me that Redux would only introduce unnecessary complexity.
I prefer simplicity and the least amount of dependencies when developing. In my experience it makes it both easier to maintain and change your apps but it also makes it easier to introduce other developers to how your app is working.
@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.
RTK is still the best one out there. The only concern I have with it is the `extraReducers` thing :D It looks wonky.
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
talk more about redux :)
I thought you were a xstate guy?
I contain multitudes
Since Redux is one of the oldest React state libraries out there, it's often used for situations where it's not the best tool for the job.
There's a lot of choice today, but I feel the backlash against Redux has gone a bit too far - Redux still has a very effective strength, and that's how easy it is to debug complex state (thanks to its strict flux architecture and excellent browser extension).
Even though I usually use Recoil/Jotai/Zustand for my personal projects, in enterprise apps which have simple UI but complex business logic, I end up using Redux because I value debugging and traceability more.
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.
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.