The whole things about "rules of hooks" should tip people off that it's sketchy. I mean, have you ever actually thought about how:

    function Component() {
        const [state, setState] = useState(1);

        return <>{state}</>
    }

Hooks are literally javascript in the sense that they're functions you can call in javascript, but they don't operate under any of the rules people actually think of when they write javascript. If for any `function x() {}`, `if (condition) { x() }` was a fatal error, people would consider that terrible API design and the function shouldn't need to care whether it's called conditionally.

Sure, react hooks 'compose' better than class components, but they also don't compose *at all* with anyones mental model of how JS works. What they needed was different syntax or a DSL in general (what svelte does is a lot more understandable, imo).

[0]: jsx is a DSL but it's merely one bit of syntax sugar. they needed a hell of a lot more.

Hooks are called every render, which is a relatively transparent process that happens all of the time. All hooks have to be called every render, otherwise you're breaking the rules of hooks. The reason why is because the only way hooks know which hook they even are, is the order in which you call them.

For example, if I have

    const a = useRef(true);
    const b = useRef(false);

Then there are all of the closure problems with useEffect and useCallback that I see people really struggle with.

And useState...lordie. The fact that it defers setting the state value, whereas useRef will immediately have its value updated. Deferring useState has caused so many bugs.

    const [foo, setFoo] = useState("abc");
    const [bar, setBar] = useState("123");

    const [bar, setBar] = useState("123");
    const [foo, setFoo] = useState("abc");

I love the idea of hooks - the more I can isolate my logic, the better. The useState example I'm pretty ambivalent about, for the exact reason you state.

* React stores the state for your hooks in a list which is iterable.

* useBlah is just a normal function that internally calls next() on that list to get the next hook state which is why order matters.

* React checks that the iteratior on the list is at the end to see if you’ve consumed all the hooks and throws an error if not because it’s indicative of a bug in your code.

Like at this point the only thing I can recommend is try writing a toy implementation of hooks and see that they’re not magic, they’re just normal JS, and that the restrictions flow naturally from the implementation.

Like why do you want so bad for hooks to be weird?

Personally, I think that may be the piece that makes it feel a bit magical. With `this.setState()`, usage of `this` makes me feel like I know how the component and the state are linked.

With hooks, however, there's no obvious link to the component in the code. I'm grabbing `useState` off of the shared react module, `useState` is not passed into the component, and I don't have to reference the component itself at any point while using hooks. The new sets of rules you have to follow to make things line up correctly play a part, as well.

Of course that may be how `this.setState()` does it anyways - you know better than I do, obviously. Maybe the usage of `this.setState()` made me feel confident in something I didn't actually understand under the hood. But at least for me, that's why `useState()` feels a bit magical at first glance compared to `this.setState()`. Not _too_ magical, and not enough to scare me away from using hooks, but still a bit.

Hooks reveal two major things with React:

1) React developers did not understand the component paradigm that they originally went with. If they did, then they would understand how silly it is that components cannot reuse logic. This was an entire debate many years ago. Composition vs. inheritance. You don't need to throw out classes or objects to get reuse.

2) React developers do not understand functional programming. I could write an entire essay on this. But it should suffice to say, FUNCTIONS DO NOT HAVE STATE. What React hooks introduce has more in common with dynamic scoping, of older LISPs. It fundamentally breaks lexical scoping, which is incredibly important for understanding code flow. You have to be constantly aware of when it's safe to use certain variables and the implications of using variables in certain scopes now. In 2020!! This is INSANE.

I feel like the React team did a bad job at communicating that the functions are still stateless. The functions themselves never hold state, they just access the state that react holds for each component through hooks.

I think this confusion is further fueled by the fact that most people feel

render () {

    return <Button />

calls the `Button` function inside `render`, but what it actually does is that it registers the `Button` function in React, telling it "here's how you can create what I want", it doesn't actually call the function. The actual call is done by React, if and when it wants to.

Hooks extends that idea by letting you say "Here's how I want to update my component".

The component functions you write in React are a "description" telling React how to create that component. With hooks you can now "describe" how to update that component with new changes. I feel like hooks force you to let go of the control you thought you had with class-based components. Whether that's a good thing is up upto you.

Conceptually Hooks are modeled as "algebraic effects" feature from languages like Eff and Koka. Those are essentially like resumable exceptions.

With that conceptual model, `useState` is like a `throw` that goes back into React "up the stack", and then goes back into your code.

Of course that's not how it works for perf and other reasons (there's no resumable exceptions in JS). But this may help the conceptual model around how we know which component it is.

Hooks have their share of weird issues; they explode if they're called in a different order/number from how they were called the first time the component rendered (making them not at all pure functions), and it's super easy to screw up the dependency array to useMemo/useCallback (so either your hook is useless and re-installs the event handler on every render, or you get stupid "the callback had a stale copy of the state" bugs not possible with class-components).

I've also seen my fair share of situations where what would have been a this.setState with a callback becomes a tangled mess of useStates and useEffects, or someone bends over backwards to try and avoid re-installing an event handler every time one of the props or state variables it uses changes.

The machinery behind the scenes might be ugly, but this syntax is also what I love about React Hooks.

I was preferring closures to ES6 classes before using React, despite the performance implications.

Since switching to TypeScript I also like ES classes though.

Especially for things like MobX... but even without it.

Regardless of React, I feel like classes are the context where getters and setters feel most natural and ergonomic.

And classes are great for grouping state and behavior in an easy-to-understand way.

Which brings me to where I disagree with you that React team has their act together. If anything, the hooks API is tacit acknowledgement that they messed up on component lifecycles and their original component model and really don't know what they are doing. If you go back even a year earlier, most people seem to have forgotten that they redid their entire set of lifecycle methods before scraping it all for hooks. They haven't been able to get a stable API together because, architecturally-speaking, they don't know what they are doing.

The only alternative explanation is that hooks is the React team trying to remain relevant through a misguided API "refresh". Which is definitely not a good look for anyone wanting to take a framework seriously. Outside of Facebook, literally no one has the money to rewrite their app every year. Hooks aren't even backwards compatible. It's not even self-compatible with its current version! Since you can't mix hooks and classes. Just insane.

The order of hooks is only important insofar as they do not change between rendering. That's it. Hooks should always be called, and always in the same order.

A basic React Hooks component has way less boilerplate involved than a class component does, and hooks allow for much better code architecture when it comes to separation of concerns.

React seems like it’s getting more complicated every single day. I loved it due to its simplicity but now i’m not so sure.

The fact that each time you call useState in a render method you get back a different value should be a clue.

You have to have a fairly sophisticated/twisted mental model of a react component’s function signature as effectively including each of the hooks it requires to be able to mentally model hooks as pure functions.

Hooks are a clever imperative hack that works only if you stay in the strict subset of JavaScript behavior that react expects, but which lets you get the benefits of some algebraic-effect-like contextual handling that would be easily expressed in a functional syntax, but they’re not functional.

Mind you, an OO person might equally say they are an imperative hack to get you the benefits of dependency injection that would be more easily expressed in an OO syntax, but they’re not OO.

What hooks are is more ‘imperative reactive’, I would suggest.