I absolutely acknowledge this is a possibility, but I think I do understand why people use it. Because they're easy, hooks are just so god damn easy to use. Want some state? Just chuck in a `useState` and call it day. But the problem is, they're not simple, and that complexity will grow and grow until it makes the app unmaintainable. I've seen this happen at three different companies I've worked at.

To me the main benefit isn't that they're easy, it's that they're composable. They allow you to reuse "business logic" in multiple components. If it's getting too complex then that's presumably when you ought to be creating a custom hook which wraps up some of that complexity.

I'm not familiar with react hooks, but when I read what you write, my immediate reaction is: we already have a way to reuse business logic. It's called functions. Define a function and use it, either a global static function or pass it down to the component if you want to mock it.

Reading the react docs, I find this part interesting:

> Hooks were designed with static typing in mind. Because they’re functions, they are easier to type correctly than patterns like higher-order components. Importantly, custom Hooks give you the power to constrain React API if you’d like to type them more strictly in some way. React gives you the primitives, but you can combine them in different ways than what we provide out of the box.

(https://reactjs.org/docs/hooks-faq.html#do-hooks-work-with-s...)

Seems to me as if hooks try to fix the lack of a good programming language. These approaches usually go wrong eventually. Maybe it's time to ditch Javascript (and even Typescript) and use a proper language (purescript maybe?) so that all these things can be done with just functions.

> I'm not familiar with react hooks, but when I read what you write, my immediate reaction is: we already have a way to reuse business logic. It's called functions.

Hooks are functions. If that wasn't obvious, it's also explicit called out as a key thing about them in the excerpt from the docs that you present and then try to make a point with that entirely ignores the content of the excerpt.

Apologies. When I said "functions" I meant "pure functions" in the sense that you can call them anytime and don't need to consider any special rules. An example would be `Math.pow`.

Hooks are not _just_ functions, they are special functions where that (by the documentation) should not be called inside loops, conditions, or nested functions. These are severe restrictions compared to the "normal/pure" functions that I meant.

One key difference between hooks and functions is that hooks tap into some hidden global component registry (I'm being handwavey here but this is more or less what happens). This allows side effects to be persisted and tracked between function calls.

You can probably build all this infrastructure yourself without hooks and only with plain functions. It'll involve some global store and some subscription mechanism. You'll end up with something really similar to Redux.

> You can probably build all this infrastructure yourself without hooks and only with plain functions

It sounds to me that such a concept would be very useful in a lot of contexts, so instead of specializing it only to react hooks, it might be better to just be a standalone library. E.g., why not use the same technique in Angular?

That way, developers don't have to learn framework-specific ways of doing things again and again but can reuse their knowledge. I think the fact that everyone is building their own thing is one of the reasons why many people have this notion of "need to learn a new framework every half a year". Backend technology seems to do better here, maybe because the pace is slower?

> it might be better to just be a standalone library

See: https://github.com/reduxjs/redux, among others.

The React ecosystem did exactly this for the past few years, but evidently it was decided that a more native approach like hooks were better.

I know redux, but I believe that there should be an even more low level library.

Coming from the backend, I miss something like the effect system builtin in Haskell/Purescript or added as a library to languages like Scala (e.g. https://typelevel.org/cats-effect/) or Kotlin (e.g. https://arrow-kt.io/docs/effects/io/)

Hooks are not an alternative to redux, although you could use then as one.

Personally, any time anybody has ever suggested using redux I have always fought it. I've never seen the news for a global state management library, since react has always had tools to manage state built in.

One thing you are missing is a lot of organizations don’t care about UI tests. They’re brittle and the UI is always changing anyways so you get diminishing returns from writing many of them. Usually an end to end test is enough. UI logic is usually not that complicated, if it doesn’t work you will know right away. Hooks are acceptable.

I have used them on a medium project. I enjoy them very much but I have seen a lot of people struggle with the "rules of hooks"*

I can see why some people prefer to use classes where the design is cleaner (even though you are more limited).

*: https://reactjs.org/docs/hooks-rules.html#:~:text=Only%20Cal....

If you use a linter though you can just auto enforce all the rules and back to it being just fine. An extra setup step but tools like create react app bundle ESLint for you already so I don’t mind it.

I actually think the problem is a lack of critical thinking. When Hooks were announced by Dan Abramov, people were hailing him as a genius etc, that this was a panacea.

A lot of successful people use Cobol too

Yep, but not voluntarily on greenfield projects unless I'm missing out on the latest trends from the Valley ;-)

Fair enough. Still "successful people use it, so it must be good" isn't a valid argument for me.