Hi Amy,

I really liked your article. Probably I over-reacted a little because it seems that the origin of all problems are because of hooks, but I believe that you did an impressive job. My apologies if I upset you.

As far as I know, the problem is not in hooks. Basically, because I can rewrite any hook as HOCs and any HOC as hooks. The main difference is that HOCs forces you to split components, but that does not guarantee that you do not mix HOC logic with component logic, so you can end in the same problem.

Although I can translate from one to the other without struggle, the reasons that I prefer a hook instead of a HOC are:

• people get confused with the high order components
• you often cannot choose the name of the props in which the HOC injects things,
• the code in the HOC gets split across several functions, and it is difficult to maintain,
• often you lose the ref,
• hooks are easier to debug (although, I do not like debugging :P)
• a chain of hooks is easier to read than a chain of HOCs
• people handle better props with hooks than with HOCs, the reason is they often only consider the prop initialization, and they fail to consider when the prop changes

The points about SOLID are essential. I think that they are the best contribution of your article. As you have said, there are countless bad hooks, but I prefer to notice that not all hooks are bad. I think that because they have a lower entry barrier, there are more low-quality examples than good ones. Instead of telling people that hooks are bad, and HOCs are good, I would suggest encouraging them to be aware of it, and fix it. There is no reason why people could follow SOLID and write hooks at the same time.

And thank you so much for the article, I hope a lot of people can read it and learn from it.