Discussion on: A Hooks-vs-Classes Report Card

[Greg Fletcher]

Thanks for the article. I enjoy reading your POV!

I fall on the other side of the discussion concerning functions (Hooks) vs classes in React, but I've got nothing against classes. I use them in other projects but not React since the Hooks API (IMO) is much simpler than the classes one. Sure, developers sometimes still make messy code (me) that's hard to read but I believe that Hooks give you a better head start to make things simpler. Plus, packaging up state management in a custom hook for reuse is a great API that I use all the time.

Thanks again for the article. I appreciate the effort you put into it. It's super important to have these discussions and I look forward to more.
Cheers!

[Adam Nathaniel Davis]

Thanks for the feedback! I'm genuinely curious about this statement:

Plus, packaging up state management in a custom hook for reuse is a great API that I use all the time.

How, precisely, have you chosen to do that? I'm asking because I wrote an article highlighting a particular technique that I've discovered (dev.to/bytebodger/hacking-react-ho...). But I've also found a lot of misinformation around this topic. When people make statements like this, it often sounds (to me) like you can just create a custom Hook that uses its own state, and then you can just use that custom Hook wherever you want, throughout the app, to share that state - but... it doesn't work that way. And I rarely hear people talking about the specifics of how to make that work.

So I'm genuinely curious to see the approach you've taken.

[Greg Fletcher]

Good question. I'll do my best to answer below.

It's key to note that Hooks do not solve Global state management. They're just a different API for state management in general, whether that be local or global state. If you want, you can use context, prop drilling, etc for your global state management. But Hooks were not made specifically for the global state problem, just state.

So what do I mean by packaging up state management for reuse?

I can (potentially) reuse that custom hook in another project without changing the code. I say potentially because it depends on how well the hook was written in order to make it reusable in another project.

import useFetch from './hooks/useFetch.js'

function SomeComponent() {
  const data = useFetch("someurl/get/me/data");

  if (data) {
    return <NeedData data={data} />;
  } else {
    return <Loader />;
  }
}

This has two potential benefits.

1. I can extract state management, logic, whatever else you might be doing, and put it into a custom hook and now my state is no longer clogging up my component. Less lines of code for me to read when scanning over it. This is a big deal for me because it helps me understand the flow of the component that I'm making.
2. I can also reuse the same custom hook in the same app or separate projects. In this case, we are not sharing state, only the functionality. To me, this is a big win because we are closely following the DRY principle.

As far as sharing global state deeply into your app , that's still the same as ever. Either use prop drilling, context, or some library like Redux.

By no means am I saying that Hooks are perfect, but IMO they're a step in the right direction.

As far as rendering state deeply in your hacking-react-hooks example you could use the children API.

function TopLevel() {
  const { increment, decrement, reset, invert } = useCount();

  return (
    <div>
      <MainApp>
        <Header />
        <CountingPage>
          <Larry increment={increment} />
          <Curly decrement={decrement} />
          <CurlyJr invert={invert} />
          <Moe reset={reset} />
          <Text />
        </CountingPage>
        <Footer />
      </MainApp>
    </div>
  );
}
function MainApp({ children }) {
  return <div>{children}</div>;
}
function CountingPage({ children }) {
  return <div>{children}</div>;
}

[Adam Nathaniel Davis]

Excellent response - and sincerely appreciated! When I look at the example you've given with the children API, it strikes me as "I'd do this with Context". This is not to imply that your example is inferior or that mine is "better". Just different paths to the same result.

In some ways, your response has also further-solidified what is (IMHO) a central "issue" with Hooks. Or maybe it's just an "issue" with JS devs. I don't know.

But the "issue" I'm talking about is that, when I've heard people describing Hooks, I've become attuned to the concept that they're almost speaking a different language. A "Hooks person" will often say "Oh, I use Hooks to share state" and "non-Hooks person" will hear that and have an entirely different idea about what the "Hooks-person" was trying to communicate. Then the "non-Hooks person" sits down and starts playing with Hooks - and the constructs don't seem to support everything they were hearing from the "Hooks-people".

To be absolutely, 100%, crystal clear on this, I am NOT saying that this is some kind of "fault" with Hooks, or with "Hooks people", or with React in general. It just seems to be, IMHO, a strange dichotomy that has been building in the React community. Neither side is "right" or "wrong". But it still feels to me like... a problem. And I have no idea what (if anything) can be done about it.

This is what I was trying to get to in the "Developer Cognition" part of the article. I don't honestly think that either "side" is right or wrong. It just feels, increasingly, like there are two different... dialects being spoken.

All that being said, I think the examples are excellent and they've given me some good "food for thought". I appreciate the time!