DEV Community

Discussion on: Reinventing the Wheel With React Hooks

Collapse
 
isaachagoel profile image
Isaac Hagoel • Edited

I would like to add a few points:

  1. Functional components with hooks are no longer functions (the way functions are normally defined. In JavaScript a class is also a function under the hood, see developer.mozilla.org/en-US/docs/W... ). They are in fact what's knows as modules (because they use a closures and semi global variables to persist state). Needless to say, they are not pure in any way, shape or form. Imo, React ruined functional components by introducing hooks because now when you see a functional component in the code you can no longer make any assumptions about it.
  2. I think the main motivation for hooks is enabling the up and coming concurrent mode
  3. The fact all hooks run on every render and then need to bend over backwards in order to bypass this behaviour (dependency arrays, using callbacks, memos and whatnot) could be funny if it wasn't so sad.
  4. Custom hooks are pretty powerful and do add new capabilities to React. I wonder what prevented the react team from supporting hooks for class components as well
Collapse
 
bytebodger profile image
Adam Nathaniel Davis • Edited

4) I feel entirely confident that I can answer that for you. In fact, it was kinda the underlying point from this post. I'm not even joking or exaggerating when I say I'm convinced that the Redux / Hooks / Abramov team is front-and-center in the JS elitist war against that ugly, nasty, evil, unconscionable class keyword. Seriously. I'm pretty sure that they just hate the idea that they might have to use class in their own code, or see it in anyone else's code.

I'm not claiming that Hooks are a one-to-one port of class-to-function, but they're pretty close. I truly believe that the underlying motivation for the creation of Hooks was a deep desire to "exterminate" that horrible class keyword from the code. And I'm equally confident that the Hooks team would rather saw off their own leg than have to extend any Hooks-based features back into class components.

IMHO, one subtle sign of this is with create-react-app. I use that package frequently whenever I need to spin up a quick, local, proof-of-concept app. It's quick and easy and convenient.

But I started noticing a few years ago that create-react-app's base install changed in a clever little way. Now, when you spin up a new project with it, the default App.js component is created as a functional component - whereas, in the past, it was always created as a class-based component.

Of course, if you still want to use class-based components, it takes all of 30 seconds to change it. And even if you leave the default App.js component as functional, that doesn't stop you from writing new components in the project that are class-based. But I felt that this subtle shift was telling. It was like having Abramov standing behind you and whispering into your ear, "Don't use those rotten no-good class-based components."

Collapse
 
bytebodger profile image
Adam Nathaniel Davis

1) That's so funny cuz I was literally laying in bed last night pondering this same issue - but from a more theoretical standpoint. I've had it drilled into me from my earliest days as a programmer that:

A function does one thing, and does it well.

It's one of the simplest, and most powerful, concepts for writing better code. When reviewing code with other senior devs, you'll almost never get any argument about: "I broke this code up into separate functions that each do a specific piece of the work."

But functional components (especially those with Hooks) are the antithesis of this incredibly basic programming concept. JS purists start to get an epileptic fit whenever they see that dirty nasty 'class' keyword in someone's code. They start climbing up on their functional-programming lectern. They start to sound as though they alone are responsible for the holy sanctity of the language.

Then they create a functional component that itself contains half a dozen other functions. And it uses state. And context. And handles display. And it provides post-rendering with useEffect.

And... this doesn't seem to bother any of the "purists" who are so affronted by the mere sight of the class keyword.

Collapse
 
isaachagoel profile image
Isaac Hagoel

I agree about some hooks being much nicer than others and feel natural while some feel straight out forced (probably in the name of replacing classes completely as you said). I think it is fair to call the original functional components pure functions. The get props and input and emit jsx (always the same jsx given the same props). You could, in theory, do side effects inside (like making an ajax call) but that would result in terrible performance and wasn't the intent.

Collapse
 
bytebodger profile image
Adam Nathaniel Davis • Edited

3) I'm sure I'm gonna delve into this in some future blog post.

Hooks with useState()? Sure. I love it. It's simple. Easy to manage. Intuitive. Give me more.

Hooks with useContext()? Oh man, this is one of the strongest features of Hooks. So much cleaner and easier than doing it in class-based components - especially if you're consuming multiple contexts in one component.

Hooks with useEffect() and/or useCallback() and dependency arrays???

Ewww.

Hold your nose. Some of the stuff I've seen with useEffect() feels to me like a code smell - a genuine Grade-A fart, baked up and delivered to your nostrils courtesy of Dan Abramov himself.

Collapse
 
isaachagoel profile image
Isaac Hagoel

Don't hate on Dan. My impression is that he is one of the "good guys" even though I am far from being a fan of Redux or some of the hooks.
Here are two posts of his I think might make you see him in a different light:
overreacted.io/goodbye-clean-code/
medium.com/@dan_abramov/you-might-...

Thread Thread
 
bytebodger profile image
Adam Nathaniel Davis • Edited

Haha - you know what?? You're absolutely right! I know that in my posts, and in some of my responses, I definitely come across as some kind of "Dan Abramov Hater". And that's my fault. I should probably tone that down a bit. Cuz none of my (cranky, heavily-biased) opinions have got a damn thing to do with Abramov. And I'm certain that my tone, at times, undermines my underlying message.

To be absolutely fair, I can't point to a single quote from him, or a single post from him, or anything else directly from him, that ever made me think, "This guy's a douchebag." I can't even point to anything from him that would make me think, "This guy's professional ideas are misguided." It's not faux-humility to state that Abramov has probably forgotten more about JS than I've ever learned.

This is not an excuse (cuz again, I should really tone down the anti-Abramov rhetoric), but I just get really frustrated sometimes with the direction that I see some things going in. And then I look at the person who's perceived as the driver of those directions, and... I start typing angry shit on my keyboard.

More to the point, I get annoyed with the fanboys who follow these "thought leaders" and then pick-and-choose their own misconstrued bits of faux logic to back up their trolling. An example is the "class-based components are being phased out" #FakeNews. Abramov has never said that. The documentation on the React/Hooks site directly refutes that. But the fanboys latch onto the latest thing that was released by Their Lord And Savior, and then they start twisting the narrative to "bolster" their own immature code-shaming.

But that's got nothing to do with Dan, does it? And even as some guy who's cranking out his silly little blogs, I should be a bit more careful (and respectful) with what I write.

Good call-out!