Now the Redux portion looks okay for me - as for the comparison, I'd still say it doesn't 100% stand as the two examples just do very different things - the Context example only takes initialValue from somewhere and passes it down the tree, but you don't even have code to change that value ever in the future.
So if you add code for that (and also pass down an option to change that data), you will probably already here get to a point where the Context is already more code than the Redux solution.
Usage in the component is pretty much the same amount of code.
In both cases you need to wrap the app in a Provider (you forgot that in the context examples above)
creating a slice and creating the Provider wrapper pretty much abstract the same logic - but in a slice, you can use mutating logic, so as soon as you get to more complex data manipulation, the slice will be significantly shorter
That in the end leaves the configureStore call - and that are three lines. You will probably save more code by using createSlice vs manually writing a Provider.
But I had added the Provider in the Context example 😐
You are talking about using useReducer hook with the Context API. I am suggesting that if one is required to modify the data, one should definitely opt for Redux. In case only sharing the data with the Child Components is required, Context would be a better solution
Yeah, but you are not using the Parent anywhere, which is kinda equivalent to using the Provider in Redux, kinda making it look like one step less for Context ;)
As for the "not using useReducer" - seems like I read over that - in that case I 100% agree. :)
"I am suggesting that if one is required to modify the data, one should definitely opt for Redux." - can you elaborate? What specific advantages Redux has over using reducers with useReducer in React? Thanks!
@gottfried-dev The problem is not useReducer, which is great for component-local state, but Context, which has no means of subscribing to parts of an object, so as soon as you have any complicated value in your context (which you probably have if you need useReducer), any change to any sub-property will rerender every consumer, if it is interested in the change or not.
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.
Now the Redux portion looks okay for me - as for the comparison, I'd still say it doesn't 100% stand as the two examples just do very different things - the Context example only takes
initialValuefrom somewhere and passes it down the tree, but you don't even have code to change that value ever in the future.So if you add code for that (and also pass down an option to change that data), you will probably already here get to a point where the Context is already more code than the Redux solution.
I'm not entirely sure whether I agree on this point. Using context with data update would only take 4 more lines:
useStatein the ParentinitialValueIn the end, it usually ends up as quite some more code - see kentcdodds.com/blog/how-to-use-rea... for example.
But just taking your examples side by side:
That in the end leaves the
configureStorecall - and that are three lines. You will probably save more code by usingcreateSlicevs manually writing a Provider.But I had added the Provider in the Context example 😐
You are talking about using
useReducerhook with the Context API. I am suggesting that if one is required to modify the data, one should definitely opt for Redux. In case only sharing the data with the Child Components is required, Context would be a better solutionYeah, but you are not using the
Parentanywhere, which is kinda equivalent to using theProviderin Redux, kinda making it look like one step less for Context ;)As for the "not using
useReducer" - seems like I read over that - in that case I 100% agree. :)"I am suggesting that if one is required to modify the data, one should definitely opt for Redux." - can you elaborate? What specific advantages Redux has over using reducers with
useReducerin React? Thanks!@gottfried-dev The problem is not
useReducer, which is great for component-local state, but Context, which has no means of subscribing to parts of an object, so as soon as you have any complicated value in your context (which you probably have if you need useReducer), any change to any sub-property will rerender every consumer, if it is interested in the change or not.