A Critique of React Hooks

I've been using hooks full-time for the last year or so in a _very large_ React code base (one of the largest in the world). None of these so-called problems are real in my experience.

The first point is just whining about not wanting to learn new things -- we've on-boarded many new people onto our team in this time, and hook-based code is the easiest to understand. It's the old class-based components that are hard, and the most experienced team members work there usually to rewrite them as functional components.

The second point is only sort of true. They can interact with class-based components in a parent-child relationship. That's enough to gradually migrate your application towards hooks: any time you want to make significant changes to a component, rewrite it.

The third point is not a problem in my experience. Yes, we have rewritten some of our internal libraries as a direct result of hooks being available, not because the old ones didn't work but because we now had the tools to create a _much better API_ and took advantage of it.

The fourth point makes no sense to me. If you need to use conditions like that do something different, e.g. put the different cases ("a" vs "b") in different child components and render the appropriate one. Any programming paradigm has rules around it, and this is no different.

My response to the fifth point is "don't depend on control flow". You should be robust to evaluation order so it doesn't matter the exact order that React executes your code. If you have a execution order dependency in your code it will be highly brittle.

Ah, I used to be on this side of the fence. Now I've learned to love hooks, and aced the test (except for the last, extra BS, question).

Now the two issues I have with hooks still nag me in the back of my head, but are easy to get over:

- `useCallback` still makes new function references that wouldn't happen in class-based components. as someone who starts out with `class MyComponent extends React.Purecomponent`, that bugged me.

- easily access old props after updating. I built my components with something like `useEffect`, where mounting was considered "changing props from null to _something_", and updating was like normal:

  class MyComponent extends React.Component {
    componentDidMount = () => {
      this.handlePropsChange(null, null)
    }

    componentDidUpdate = (oldProps, oldState) => {
      this.handlePropsChange(oldProps, oldState)
    }

    handlePropsChange = (oldProps, oldState) => {
      if (didPropChange('userId', oldProps, this.props) {
        // now we know that props.userId changed, but also have access to `oldProps.userId` in case there's any cleanup that needs to happen.
      }
    }
  }

I know this is possible with functional components / hooks, but it was nice to get this stuff "for free".

> But it should suffice to say, FUNCTIONS DO NOT HAVE STATE

It's funny you say that: useState is the same model functional languages use to handle mutability.

https://docs.racket-lang.org/reference/boxes.html

You've solved the problem that hooks solve by using Rum mixins instead, and you're confused why you don't need hooks?

Right, I'd be curious to know a lot more details of the real-life use case that inspired that. My gut feeling says that there's maybe a state machine of some sort which could possibly be split into a sequence or maybe hierarchy of smaller components, but it's hard to tell specifically what the alternative might be without more details on why they thought a lookup table might be useful.