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.
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
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.