I wish people would stop saying this. Hooks aren’t functional or stateless.
Literally, calling ‘useMemo’ twice returns two different objects, because the function keeps track in internal state of how many times it has been called.
Hooks are very deeply imperative.
They are a way of obtaining some benefits that are easily obtained in functional programming via higher-order functions, but expressed in a way that makes them easily consumed in an imperative code body.
Hooks are obviously not stateless - I'm saying they were an inevitable consequence of the push towards functional components and that they represent an inferior development experience. No one needed to write 2000 words on how to use setState.
Couldn't disagree more. Do you remember all the nonsense you had to read about componentWillUpdate, componentDidUpdate, getDerivedStateFromProps, componentWillMount, componentWillUnmount? What a mess. Hooks clean up so much of that complexity.
Maybe this has more to do with how people look at these paradigms. I find the class based lifecycle methods much easier to wrap my head around than hooks. I think hooks are more of an answer to higher order components. They make sense to me when I look at them that way, but as a replacement for classes, function components seem inferior from a maintainability perspective.
Class based components are garbage. There's a reason hooks were introduced. It is analogous to OOP vs functional programming, inheritance vs composition (not exactly the same because hooks are not pure functions).
A stateless programming model in a domain where state is so fiercely coupled to program utility is inevitably going to spawn this garbage.
Class based components with MobX managing state was, and still is, a dream to write __and__ read.