What is the point of using hooks?

Question

React

Hello, I don't understand what's going on.

There were classes, there were HOCs, components were divided into Container/Component or Smart and Stupid.
They had their own areas of responsibility, nothing was mixed up, but then hooks appeared.

And if you can only live with React hooks, but when the project is not a demo, but a real one, then a bunch of different libraries are connected, every second one has hooks, in the end everything is mixed up.

Further, the philosophy of Redux, "do not dispatch actions directly", everything through actions creator and so on and so forth, now we are simply provided dispatchfrom useDispatch()

Now the component is firmly connected with the redux, and is responsible for everything at once.

How to test it?
Will we have to create a wrapper from the provider for the test of each component?

Previously, you could take a component, pass in props, and be happy.

As a result, I don’t understand where everything is going, why do they leave classes (convenient, understandable, structured) for functional components with hooks?

On demo examples, everything is clear and obvious - the components are simpler and more readable on hooks, but real projects are some kind of mess and stuffing

Answer 1

There were classes, there were HOCs

They are still there. Regarding HOC: in view of the fact that we cannot connect the component directly to the store, we have to make an additional mapStateToProps wrapper. Thus, another component grows above the component, which is associated with the warehouse. Then another wrapper withStore, withRouter and so on. In the debugger, you already begin to see a large nesting of components, and as the application grows, this already becomes an anti-pattern. This all works poorly in terms of minification and performance due to large nesting trees.

components are separated into Container/Component or Smart and Stupid

What is the problem? You can do the same with hooks

And if you can only live with React hooks, but when the project is not a demo, but a real one, then a bunch of different libraries are connected, every second one has hooks, in the end everything is mixed up.

As a rule, all third-party plug-in libraries already contain hooks out of the box, and those that do not yet will be supported in future versions. I don't see any problems here either.

Further the philosophy of Redux, "do not directly dispatch actions", everything through actions creator and so on and so forth, now we are simply provided with dispatch from useDispatch()

This philosophy holds true when using hooks. You can also dispatch the necessary actions through useDispatch

Previously, you could take a component, pass in props, and be happy.

Now you can just as easily drop any props into a component, only it is already much easier to do without any additional wrappers.

As a result, I don’t understand where everything is going, why do they leave classes (convenient, understandable, structured) for functional components with hooks?

The main 2 reasons: the rejection of HOC and the emulation of life cycle methods in functional components.

Answer 2

Just more features, you can build more flexible applications, more accurately adjust the architecture, shoot yourself in the foot (head, liver) more accurately.
No one forces you to shove useDispatch everywhere, you can still connect your containers to the redux and enjoy the clean architecture.
As they say, everything is in your hands. If the application is very crutch, then the classes will not help here either.

Answer 3

To be honest, I have never had any experience in writing class components. I always wrote only in functional ones and I actively use hooks.
The code of functional components is much simpler, smaller and clearer, IMHO. Hooks are very useful tools. You need to have separate state. Something goes to redux, something is stored directly in the state of the component itself. It also depends on the approach to organizing the structure in the project.
useState, useRef and useEffect - in general, I use it in every project, I can’t imagine how one can do without this trio. The use of the rest depends on the tasks.

Will we have to create a wrapper from the provider for the test of each component?

Yes, but let's not talk about sad things)

Previously, you could take a component, pass in props, and be happy.

What's stopping you now?

On demo examples, everything is clear and obvious - the components are simpler and more readable on hooks, but real projects are some kind of mess and stuffing

If the structure of the project is competent, the logic is separated, then everything is clear and understandable. Yes, usually the biggest pain is structure. A trillion folders of files. But isn't it already different in classes in real projects?