This pretty well miss states a lot of things about both React and React hook so let me see if I can correct them.
1) Hooks are better because they're faster/less code etc.
Actually the reason the React team built hooks is to provide a way to encapsulated and share behavior. Traditionally that was done with Render Props or Higher Order Components, those both have problems of composability and adding unnessesary levels to the tree, hooks are a better solution.
Along the same lines while the hooks that are included with React are fine the power comes from leveraging them to build bigger functionality and encapsulate that in a hook. Most of the big React libraries have hooks and using them tends to make your code more readable even if it is longer.
2) Introducing Redux concepts.
There is a "useReducer" hook but firstly the reducer isn't a "Redux" concept (see Array.reduce if you want another example), secondly the inclusion of the hook isn't about pushing in Redux patterns it's more that the React team packaged a hook that they found helpful on complex state management. There are objective reasons why the pattern of actions and reducers is good at complex state management, those are no less true when the state is in a component or a Redux store... But let's say you prefer a different paradigm for managing the state in your component. That's fine the building blocks of useState, useRef, and useEffect are there for you.
3) useEffect is a dumb replacement for lifecycle hooks.
useEffect is where the code you previously had in lifecycle hooks goes now (probably) but it isn't a replacement of lifecycle hooks. If you really care about when your component was mounted you should use the Component class still (they're not getting rid of it) however more likely you were using that lifecycle method to dispatch some asynchronous work. Moving those side effects of rendering into a useEffect hook has 2 benefits. Firstly you couple the create and clean up code together rather than needing to split it between 2 methods, that reduces errors, but also means that you can avoid setting class properties to share state between the methods. Secondly it avoids needing to ensure your code is called from all the potential lifecycle methods that should be triggering it (componentDidMount, componentWillRecieveProps, etc)
The important thing to remember about useEffect though is that it's not trying to be those lifecycle methods. Instead it's a way to tell React "after this component renders, at some point in the future do this." That is far more useful when you're building reusable behaviors than life cycle hooks.
There has also always been a bit of a mismatch between lifecycle methods and React's notion of declarative rendering. Conceptually React has always had the notion that you declare the result of the render and it takes care of the transit. In that world traditional UI framework style lifecycle hooks don't really make sense.
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 pretty well miss states a lot of things about both React and React hook so let me see if I can correct them.
1) Hooks are better because they're faster/less code etc.
Actually the reason the React team built hooks is to provide a way to encapsulated and share behavior. Traditionally that was done with Render Props or Higher Order Components, those both have problems of composability and adding unnessesary levels to the tree, hooks are a better solution.
Along the same lines while the hooks that are included with React are fine the power comes from leveraging them to build bigger functionality and encapsulate that in a hook. Most of the big React libraries have hooks and using them tends to make your code more readable even if it is longer.
2) Introducing Redux concepts.
There is a "useReducer" hook but firstly the reducer isn't a "Redux" concept (see Array.reduce if you want another example), secondly the inclusion of the hook isn't about pushing in Redux patterns it's more that the React team packaged a hook that they found helpful on complex state management. There are objective reasons why the pattern of actions and reducers is good at complex state management, those are no less true when the state is in a component or a Redux store... But let's say you prefer a different paradigm for managing the state in your component. That's fine the building blocks of useState, useRef, and useEffect are there for you.
3) useEffect is a dumb replacement for lifecycle hooks.
useEffect is where the code you previously had in lifecycle hooks goes now (probably) but it isn't a replacement of lifecycle hooks. If you really care about when your component was mounted you should use the Component class still (they're not getting rid of it) however more likely you were using that lifecycle method to dispatch some asynchronous work. Moving those side effects of rendering into a useEffect hook has 2 benefits. Firstly you couple the create and clean up code together rather than needing to split it between 2 methods, that reduces errors, but also means that you can avoid setting class properties to share state between the methods. Secondly it avoids needing to ensure your code is called from all the potential lifecycle methods that should be triggering it (componentDidMount, componentWillRecieveProps, etc)
The important thing to remember about useEffect though is that it's not trying to be those lifecycle methods. Instead it's a way to tell React "after this component renders, at some point in the future do this." That is far more useful when you're building reusable behaviors than life cycle hooks.
There has also always been a bit of a mismatch between lifecycle methods and React's notion of declarative rendering. Conceptually React has always had the notion that you declare the result of the render and it takes care of the transit. In that world traditional UI framework style lifecycle hooks don't really make sense.