you should not create complex components where you manage a lot of state - you should break them up into smaller (and potentially reusable) components, and hooks (and function components) encourage this.
This is basically what I wanted to say above 😄 But in a case where you can't avoid a lot of state in a parent component, it's better to let it be a class and all their children to be functions (with hooks if needed). One scenario that comes to mind is when you are expecting to work with some data from Redux which is then needed in children components, it's maybe better, in my opinion, to have class component connected to redux instead of using redux hooks in children. This has some problems on its own of course, as we need to take care not to cause unnecessary re-renders when the parent state or redux state is updated.
Just to be clear, I have nothing against OOP nor FP 😄 I'm using both paradigms in my code, as each one has its own use case.
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.
This is basically what I wanted to say above 😄 But in a case where you can't avoid a lot of state in a parent component, it's better to let it be a class and all their children to be functions (with hooks if needed). One scenario that comes to mind is when you are expecting to work with some data from Redux which is then needed in children components, it's maybe better, in my opinion, to have class component connected to redux instead of using redux hooks in children. This has some problems on its own of course, as we need to take care not to cause unnecessary re-renders when the parent state or redux state is updated.
Just to be clear, I have nothing against OOP nor FP 😄 I'm using both paradigms in my code, as each one has its own use case.
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? :-)