This isn't your typical piece of Hooks brainwashing, designed to shame you for using class-based components, and extolling the Ever-So-Holy Virtues...
For further actions, you may consider blocking this person and/or reporting abuse
I agree for a big part with your article. People are always using the next big thing, but that doesn’t mean it is better than the previous thing.
However, for me, hooks provide a new way to reuse specific logic. I can simply import ‘useAnything‘ and it works. Whereas with classes this isn’t possible due to different lifecycle methods. Hooks allow me to split code by functionality, not lifecycle. With classes you would need HOCs or render props to achieve the same.
So no hooks are not always better, or more readable than classes. But, for me, often they are. Luckily both are here to stay.
Good points. Hooks certainly have some advantages. I'll explore those a little further in a future post.
You can say that again.
Another point I would like to add is when the community wholeheartedly moves towards the new thing, the momentum it creates forces the people sitting on the fence to follow the herd.
The latest and chic technique gets the majority mindshare. All new libraries get developed using the new thing. Old libraries that used past practices fall into disuse and stop getting the updates and fixes.
Modern web applications rely on so many libraries that size of node_modules is a running joke. It is turtles all the down. So for better or for worse, one has to follow the latest trends.
I would like to add a few points:
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
classkeyword. Seriously. I'm pretty sure that they just hate the idea that they might have to useclassin 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
classkeyword 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 defaultApp.jscomponent 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.jscomponent 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."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:
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
classkeyword.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.
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/oruseCallback()and dependency arrays???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.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-...
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!
Spot on. And is there is anything in computer science that lends itself more to objects than UIs? Has anyone ever looked at a piece of a UI and though, "Nice function!"? Nope.
Bingo! That's a big reason why React originally appealed to me - because, when crafting a UI, you have all these... "things" on the screen. Those things have actions (events) that can be triggered based on user input. Those things have their own bits of logic (functions) that should happen at specified times, or in response to specified input. Those things have their own internal memory (state). And they have their own rules about how-and-where to generate display (the
render()).Those things... are called objects.
Well not exactly.... They're called components, not objects.
React has always been based on functional programming concepts, even before hooks, e.g. pure functions, composability, immutability, Redux, etc. Hooks are just the next logical step to making the library more FP-oriented.
I personally love hooks as I find it much faster and easier to write components than with classes (there's also a slight performance boost). Maybe you'd prefer a more OOP-oriented frontend framework like Angular?
I'm talking about paradigms here. No one with even an elementary understanding of JS thinks for a moment that
JS_Objects === OO_Objects.Find programmers who aren't long-time JS/React heads. Then tell them, "I have this thing. It can maintain its own internal memory. It has a view, through which display output is directed. It can have any number of pre-defined actions/events, based on user input, or based on conditions that are passed into it. It has a defined life-cycle. It probably has ancestors. And it can have descendants. It can exist as a single entity, or it can be cloned. The clones can be perfect copies or they can behave differently, based on the initial parameters. So... with all of those parameters in mind, what would you call this thing??"
Then sit back and count the number of people who say, "I'd call that thing a function"...
We all understand that this stuff ultimately gets transpiled down to functions (whether we start with a function or a "class"). But I (and the original commenter above) are talking about the paradigm that best fits a UI "object". (Or "component". Or "element". Or whatever particular name we want to call it.) The paradigm I'm referring to is the exact same paradigm that was directly fostered by the React framework - for years.
As for Angular, I've done a lot of Angular. I can work in it just fine - but I prefer not to. I don't particularly care for it.
Hmmm fair enough. Thanks for the explanation.
In terms of what's "easier" to reason about in React/JS, I personally find functional components easier to understand than class components. E.g. the other day I had to go through a couple of React libraries using classes. It took me a while to adjust to understanding what "this" referred to. Maybe I'm strange for legitimately disliking class components 😆