TL;DR, React is currently capable of doing what Redux does, so there's no need for the extra dependency, and you can simplify your code by removing redux.
You're correct. useContext + useReducer provides way less boilerplate code for the same functionality. I'll update the article accordingly. Thank you for the valuable comment ❤️
Your post will still be very valuable to Redux users. Not everyone can switch to useContext+useReducer right away,
Also it was tricky getting it to work, at first, because with UC+UR approach you have to make the app wait until the first render of your root component before you can manage state (dispatch actions), because you can't 'initialize it' until you're already inside a render function where it's possible to call a hook without breaking the "Rules of Hooks".
Anyway your post was very good and I should have said so too! :)
A bit of caution though when replacing Redux with useContext + useReducer. Performance might suffer a lot depending on the application and re-render scenario.
Anyway great article.
I have found that Redux really shines when updating different components connected to the same state and they are part of a large nested component hierarchy with many unrelated components that should not re-render .
And so powerful if a component itself is connected to a slice of state then it could be arbitrarily moved within the entire component hierarchy.
Also I see Redux as a sort of separation of "what happened" (event) and "how to update any state based on that event".
I'm seeing the UC+UR approach running at east as fast as with Redux. Redux doesn't have anything to do with the rendering efficiency, afaik. All that is done by the core React framework. If anything it seems like this approach is faster.
I have potentially one of the most DOM heavy (1000s of DOM elements per page) apps in the world (quanta.wiki) and it's lightning fast. But I do appreciate the warning.
I was a bit unclear, you are correct, Redux itself has nothing to do with rendering or react. React-redux has though and is what is passing updates to react in a very optimized manner.
Anyways, I have read a few articles (not trying myself) that Context has performance limitations since any component that consumes context will be forced to re-render and you might need workarounds like useMemo etc.
I don't mind if my render functions get called a lot, because even those have nearly zero impact on performance. What hurts performance is the TRUE DOM modifications when they happen.
So, for example, if I have 1000s of components "consuming context" and I make some global state change that only affects the ACTUAL DOM for one item, then only that one item will consume non-negligible CPU (i.e. DOM update). That's what makes React so fast. It only updates the DOM for things that DID change. So I'm still skeptical about those who say redux is still needed. They may have a bias.
I'm a full stack web app dev. Professionally, my stack is SQL Server/Entity Framework/.Net Framework && .Net Core/Angular 2+. On the side, I dabble in React/Redux, dApp development on Ethereum, and Go
Incorrect. useContext forces rerender on any change within the context variable. Redux uses selectors to allow components to subscribe to small slices of state change.
I have an app with VERY many DOM elements, and when I do a global state change, React is smart enough to only update the part of the DOM that actually changed, which is why it's lightning fast. You can count rerenders if you want, but those affect performance one millionth as much as DOM changes...which is why my app has the same exact performance without Redux as it did with Redux...and if anything is faster.
Yeah React is considered fast, still there are scenarios where it is not fast enough by itself or in combination with things like Context. One example is updates/re-renders that occurs when typing , animations, scrolling etc. where you might have to resort to things like Pure functions or such. Also, update the DOM is one thing, expensive calculations might also be part of a component.
Sounds like you found the perfect solution for your app though!
So I'm still skeptical about those who say redux is still needed.
It was some time ago I worked with theese things, so there might be better alternatives but this is an excellent writeup as of Redux/Context:
There are plenty of ways to shoot yourself in the foot, but if anything compute-intensive is being done in a render method that's a mistake on the developer's part, and a violation of MVC principles too.
Also my app doesn't use hardly any JSX/TXS either. I have a framework of components that calls 'createElement' directly, but all that is abstracted away as you can see by looking at how my LoginDialog renders GUI...
I just removed Redux completely from my app yesterday, and replaced it with what's shown here:
towardsdev.com/stop-using-redux-yo...
TL;DR, React is currently capable of doing what Redux does, so there's no need for the extra dependency, and you can simplify your code by removing redux.
You're correct. useContext + useReducer provides way less boilerplate code for the same functionality. I'll update the article accordingly. Thank you for the valuable comment ❤️
Your post will still be very valuable to Redux users. Not everyone can switch to useContext+useReducer right away,
Also it was tricky getting it to work, at first, because with UC+UR approach you have to make the app wait until the first render of your root component before you can manage state (dispatch actions), because you can't 'initialize it' until you're already inside a render function where it's possible to call a hook without breaking the "Rules of Hooks".
Anyway your post was very good and I should have said so too! :)
A bit of caution though when replacing Redux with useContext + useReducer. Performance might suffer a lot depending on the application and re-render scenario.
Anyway great article.
I have found that Redux really shines when updating different components connected to the same state and they are part of a large nested component hierarchy with many unrelated components that should not re-render .
And so powerful if a component itself is connected to a slice of state then it could be arbitrarily moved within the entire component hierarchy.
Also I see Redux as a sort of separation of "what happened" (event) and "how to update any state based on that event".
I'm seeing the UC+UR approach running at east as fast as with Redux. Redux doesn't have anything to do with the rendering efficiency, afaik. All that is done by the core React framework. If anything it seems like this approach is faster.
I have potentially one of the most DOM heavy (1000s of DOM elements per page) apps in the world (quanta.wiki) and it's lightning fast. But I do appreciate the warning.
I was a bit unclear, you are correct, Redux itself has nothing to do with rendering or react. React-redux has though and is what is passing updates to react in a very optimized manner.
Anyways, I have read a few articles (not trying myself) that Context has performance limitations since any component that consumes context will be forced to re-render and you might need workarounds like useMemo etc.
I don't mind if my render functions get called a lot, because even those have nearly zero impact on performance. What hurts performance is the TRUE DOM modifications when they happen.
So, for example, if I have 1000s of components "consuming context" and I make some global state change that only affects the ACTUAL DOM for one item, then only that one item will consume non-negligible CPU (i.e. DOM update). That's what makes React so fast. It only updates the DOM for things that DID change. So I'm still skeptical about those who say redux is still needed. They may have a bias.
Incorrect. useContext forces rerender on any change within the context variable. Redux uses selectors to allow components to subscribe to small slices of state change.
You should not interchange useContext and Redux.
I have an app with VERY many DOM elements, and when I do a global state change, React is smart enough to only update the part of the DOM that actually changed, which is why it's lightning fast. You can count rerenders if you want, but those affect performance one millionth as much as DOM changes...which is why my app has the same exact performance without Redux as it did with Redux...and if anything is faster.
Yeah React is considered fast, still there are scenarios where it is not fast enough by itself or in combination with things like Context. One example is updates/re-renders that occurs when typing , animations, scrolling etc. where you might have to resort to things like Pure functions or such. Also, update the DOM is one thing, expensive calculations might also be part of a component.
Sounds like you found the perfect solution for your app though!
It was some time ago I worked with theese things, so there might be better alternatives but this is an excellent writeup as of Redux/Context:
blog.isquaredsoftware.com/2021/01/....
There are plenty of ways to shoot yourself in the foot, but if anything compute-intensive is being done in a render method that's a mistake on the developer's part, and a violation of MVC principles too.
Also my app doesn't use hardly any JSX/TXS either. I have a framework of components that calls 'createElement' directly, but all that is abstracted away as you can see by looking at how my LoginDialog renders GUI...
github.com/Clay-Ferguson/quantizr/...