Right, yes all of that makes sense ... sometimes you naturally just need a component that manages a larger number of fields and breaking it down doesn't buy you anything. And replacing that with two dozen "useState" calls doesn't look like that much of an improvement over doing it in the conventional way.
Your remark about Redux is spot on, I came across two articles explaining the issues when replacing Redux with its "connect" API with hooks:
"When you move away from connect you lose a lot of the performance benefits it provides. This means that you’ll have to be more cautious when considering re-renders and passing data from smart and dumb components"
(core issue here: "connect" does some smart things that result in less re-rendering out of the box and which you would have to manage yourself with hooks)
By the way I see now that these are really 2 different topics, the first article is about replacing Redux with useContext/useReducer, the second is about replacing Redux 'connect' with the new Redux 'hook' API (useStore, useSelector, useDispatch and so on)
But the conclusion with either was that you had to to put in extra effort to get the performance which Redux with hooks gives you 'out of the box'.
Anyway, the pattern where you have a "master" (class) component with Redux/connect and then a bunch of stateless child components (with hooks if needed) probably makes sense. It's almost as if the master/parent component is the "controller" from the classical MVC paradigm? :-)
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.
Right, yes all of that makes sense ... sometimes you naturally just need a component that manages a larger number of fields and breaking it down doesn't buy you anything. And replacing that with two dozen "useState" calls doesn't look like that much of an improvement over doing it in the conventional way.
Your remark about Redux is spot on, I came across two articles explaining the issues when replacing Redux with its "connect" API with hooks:
staleclosures.dev/from-redux-to-ho...
Quotes - regarding when you want to move from Redux to the "Context" API with hooks (useContext / useReducer):
"Without relying on Redux you lose out-of-the-box performance optimizations ..."
"Optimizing rendering performance is now your job"
And:
itnext.io/how-existing-redux-patte...
Quote:
"When you move away from connect you lose a lot of the performance benefits it provides. This means that you’ll have to be more cautious when considering re-renders and passing data from smart and dumb components"
(core issue here: "connect" does some smart things that result in less re-rendering out of the box and which you would have to manage yourself with hooks)
By the way I see now that these are really 2 different topics, the first article is about replacing Redux with useContext/useReducer, the second is about replacing Redux 'connect' with the new Redux 'hook' API (useStore, useSelector, useDispatch and so on)
But the conclusion with either was that you had to to put in extra effort to get the performance which Redux with hooks gives you 'out of the box'.
Anyway, the pattern where you have a "master" (class) component with Redux/connect and then a bunch of stateless child components (with hooks if needed) probably makes sense. It's almost as if the master/parent component is the "controller" from the classical MVC paradigm? :-)