Hooks are a great start, I hope people embrance the functional paradigm more and we don't have another hype cycle of OOP for some reason ..
If you put a hook in your functional component, it's not functional anymore.
The whole point of functional code is that I'm minimizing state, and writing code that's pure - It will always do the same thing given the same inputs.
And that whole guarantee really gets thrown out the second you embed a hook in the function.
Now, that said - I also prefer react with hooks. To me they compromised on the push for functional code in order to make working with side effects and state easier.
Hooks feel a lot nicer than having to wrap a pure component in a HOC to get the same effect - but it lulls folks into complacency because they are actually dealing with side-effects, and now the boundary is a lot murkier, and comes with a completely different (and not particularly intuitive) set of rules around how to safely use hooks.
The main point of fuctional paradigm in engineering is composition over inheritance. Hooks give us that, and a way to escape classes (and people who really want to write JS like Java).
This isn't my goal with functional programming. My goal is to minimize side effects.
I want code that is repeatable, consistent, and easy to test. I want front end code that's as close to a pure projection of state->DOM as I can get, because that makes all sorts of problems simply vanish (And the less state, the better!).
I like hooks, mostly - but lets not pretend here... they're only functional if you don't look at the man behind the curtain.
it's a variable inside a function -- how am I supposed to test its state from outside (ie. test runner), without resorting to ugly hacks?
And if you want to test the component using it, you simply mock the hook and make sure the mocked hook returns all the value you want to test. What goes inside of the hook is outside your concern when testing the parent component.