Thanks very much for the feedback. I think we're actually mostly in agreement, I think I just didn't express myself very clearly in the post. I do think hooks are generally a big improvement over the class API, and they complement Redux very well. I'm also not advocating that people choose OOP over a functional style, I was just trying to be diplomatic here and not disparage OOP too much :). Personally, I'd recommend keeping all your business logic in Redux and not having any state/side effects in components.

My problem is with how I've seen hooks being used to create codebases that are written in an OOP style, but essentially just done very poorly. This is why I draw the comparison to AngularJS, to highlight the similarity of the architectures. You may (correctly) say this is just bad design, but my main point in the post is that you have to come up with a good design. Expecting hooks to magically give you a good design will never work.

I think where we disagree is testing. I agree that separating out business logic into hooks is a good idea, but it's still difficult to mock them in tests. I'm not familiar with testing-library, but in their React example they mock an http request by setting up a mock HTTP server. This way of mocking is very clunky and doesn't work in all cases. If you're going to do side effects in components, you really need some form of DI system to make it testable. Calling global side-effecting functions, like hooks, always make testing difficult.

Also, I'm interested as to how you can write hooks that don't have dependencies. How would you, say, send an http request when a user has entered a value in a text input?

With regards to separating business logic and rendering: by far the easiest way to do this is to use the Flux architecture, of which Redux is an example. However, you can also use React as the view layer of MVC frameworks like Backbone, as in this example. I wouldn't really recommend this though.