that's interesting because I always find HOC a cleaner abstraction. Take for example accessing context, the HOC way (such as in recompose) is seen as a form of dependency inversion, which is one of the SOLID principles. The hooks way (and in fact all of the THREE official ways) can be seen as some form of the service locator antipattern.
HOCs let you stay in the simple mental model of view = component(props). When you want to do anything more than that like effects or injecting a context, you do it outside of said component. HOCs make it very easy to unit test and eliminate containers just like hooks.
I do see the need for hooks for low-level libraries (primitive-components-level), it enables a high level of composition without the downside of a bloated component tree as seen in HOCs. For application-level composition, I prefer HOCs though.
I guess that's okay, it's exactly why the React team isn't making classes and HOC's go away :) Personally, I feel that hooks are more in the "spirit of React", but at the same time, the spirit of React is to have more than 1 way to do things, so this is just some healthy variety
We're a place where coders share, stay up-to-date and grow their careers.
We strive for transparency and don't collect excess data.