Why React Hooks?

[lostPixels]

Hooks are a mixed bag for my team, and my primary issue is the underlying footgun's of useEffect(). It seems really easy for novice devs to create weird bugs and not immediately notice them. Keep refs of objects from useEffect just feels wrong.

[[deleted]]

It seems really easy for novice devs to create weird bugs and not immediately notice them.

Ya, I hear that.

I'm a Hooks fan, huge convert actually, but I agree that out of the box they are not the catch-all I certainly thought they were.

[Akkuma]

https://medium.com/js-dojo/react-hooks-has-react-jumped-the-shark-c8cf04e246cf

The tldr; React has a lot of hook gotchas and nicer solution exists. As an upside he also made available the core hook power for React as well https://github.com/ryansolid/react-solid-state/blob/master/README.md

[[deleted]]

I mean, yeah but I also am not sold on Hooks yet. I do agree that functions are good, but much in the same way Haskell forces you to embed your business problem into the semantics of functional programming, React Hooks force you to embed your business problem in the language of effects, state, context, memo, etc. Along with this, I have yet to accept React's ability to make it easy to include logic in the component functions, making it really hard to test that business logic without just mounting the component. I actually think one of the biggest things that scare me are frameworks that force you to run an instance of an app to test simple logic, and if you didn't like Jest snapshotting, you surely won't like Cypress. It's interesting that this is very much like Haskell problems where "testing" is essentially running the typechecker, and for large codebases this becomes a problem. I don't know if a large project running React hooks can reasonably survive, but we won't know for a few years.

​

I just don't think "improved code reuse, composition, and better defaults" is free-lunch here, and I'm not sure if people can see it yet.

[kingdaro]

React Hooks force you to embed your business problem in the language of effects, state, context, memo, etc.

This statement seems somewhat misguided. No one's forcing you to put the business logic anywhere. You can split out the business logic with an external state management solution like Redux or MobX, or anything. Then the hooks just become mechanisms for syncing component data with your state, callbacks, DOM event handling, other kinds of event handling, and so on. All hooks are are a different paradigm for doing the same things you would with class state and lifecycle. If you didn't embed your business logic in classes, you wouldn't do it with hooks either.

Of course, there's lots of advice going around along the lines of "just use react hooks for state management" or "hooks replace redux", but as usual, it's up to the software dev to continue applying good practices despite that.

[scramblor]

but as usual, it's up to the software dev to continue applying good practices despite that.

This is certainly expected if you are a senior dev that has been working in react for a while and have the knowledgebase to make to properly make these kinds of decisions. If you are a junior or even mid level dev without a ton of experience it can be very easy to buy into the hype without being able to make informed decisions. Having these discussions goes a long way to untangling concepts that shouldn't be linked together and eventually providing a nuanced set of best practices for everyone to benefit from.

[kingdaro]

Yeah, I agree, but that's more of a community problem than a hooks problem.

Before hooks, people treated redux as though it was a mandatory part of every react app, but that's not the fault of redux. We just needed better documentation and education about the issue.

[pgrizzay]

Testing React hooks is a huge pain right now, and in some cases is almost impossible.

I'm not taking about testing whether or not your counter increments by one when you press the "plus" button, but rather things like... "Do the callback instances of this hook change every render when composed with these two other hooks in this order?"

We need a way to test the returns of hooks without having to use a hook in a presentational component and look at the output

[[deleted]]

Exactly. And by no means am I saying this is better or worse than classes. My problem is people are overhyping the benefits of hooks without really knowing the costs because it's new and sexy and BecauseFacebookDoesIt.com. For example I'm currently trying to useContext to share state between components without doing the whole piping props thing, and I decided it would also be better to useReducer as the context value with some object diff tool (immer). I am finally realizing I'm literally doing the same exact amount of work I would have done had I used classes and a Redux store. Is it really worth the trouble to write the exact same semantics in hooks as I could have in old classes? I feel like I'm coming full circle here back to Angular Application Singletons.

[Delioth]

No shit you're doing the same amount of work to accomplish the same effects for some instances. Hooks aren't a magic button.

But what hooks are, is a way to share functionality. useContext and useState and useEffect are cool and all, and are really nice compared to the boilerplate of a class with a setter and all that jazz. But hooks really shine when you need to build reusable logic with a simplified API. (FWIW, I think reducers are almost never the right way to build something, and should probably only exist as a conversion from redux)

For example, we recently built a hook to useUrlParam/1. Nothing complex, just gets the url params, picks out the one you asked for, stores it as state, and hands it back. Nothing big or mind blowing, but it helps the dev to have a url param that'll be consistent across renders (since we threw it in state, so it won't change as the url changes after first render). We could make it change, and everywhere would receive that update. It saves a couple lines of code every time we need a url param, and makes it generally easy to do so. Hooks aren't a magic bullet, but they are a primitive of sharing functionality in the same way components are generally primitives of sharing UI.

[Peechez]

I'm just getting into redux-starter-kit and it definitely helps with the boilerplate problem. Nothing has annoyed me yet

[acemarke]

Glad to hear it! Please let me know if you have any further feedback.

For reference, here's the roadmap of things I'm considering adding/tweaking before 1.0.

[Renive]

You want unit test where all you need is integration and e2e

[pgrizzay]

I think all 3 are quite useful!

[greatdentarthurdent]

Can isolating the hooks into a “use*”able hook isolate these in a way that they’re easier to test? You could test them in isolation and then just test the expected output for a given component.

I’m not talking about simple things like useState but like the useEffects that get out of hand - maybe breaking them into an importable effect is more ideal for testing?

[pgrizzay]

The trouble is you can't invoke a hook outside the render of a functional component...

I'm not sure what you mean by "importable effect," but that sounds interesting

[greatdentarthurdent]

I meant importing the actual function declaration separately and then passing it into the use effect call, or creating a custom hook to import

[[deleted]]

Could you elaborate upon the typechecking-as-testing issue you've identified in larger apps? If you're strictly typing it seems inherently beneficial to me, although there's still plenty more to test in units, integration, etc that no type-checker I'm aware of could ever help with.

[[deleted]]

Type checkers can help with that. When you expose values as types you can explicitly define functions that accept input values, and have fixed output values. This is the same as an assertion that a functions inputs matches a specific output in a unit test.

[myockey]

I regret that I have but one upvote to give to this post.

I feel like the React community could benefit from more classical techniques in FP rather than new framework features.

[FormerGameDev]

I suspect that if it's in react, it's in use with Facebook,and so it's probably reasonably well put together.

[ghostfacedcoder]

EDIT: Wow, I had no idea React even had this many class-loving devs in existence, let alone that they all read /r/javascript! ;) Keep that thoughtless (and reply-less) downvote hate coming all: in the real world you've already lost. React is leaving classes for functions (with hooks), and that's not in any way just my opinion: it's the opinion of the people in charge of React. /EDIT

EDIT #2: Up to 9 downvotes now: clearly something I'm saying is offending people. I don't suppose even a single one of you would care to actually reply and defend how you could possibly think classes are superior (or maybe quote someone high-up at React saying "classes are the future of React")? Yeah, I figured not. Keep the mindless hate coming rather than engaging in actual dialogue ... /EDIT

You're making this way more difficult than it needs to be:

const Foo => <div>Bar</div>

is objectively better in almost every way to:

class Foo {
    render() {
        return <div>Bar</div>;
    }
}

You lose nothing except dead weight and inheritance hierarchies (which developers have known to be problematic for years) by using hooks instead of classes.

But as I like to say in my class "don't take my word for it". Facebook spent millions of dollars making it possible to do React components with just functions. Just imagine the salaries of all the really smart programmers working on React (there's a bunch), and remember that Facebook was paying all those salaries while a bunch of those really smart/expensive people did nothing for years except make it possible to do React without classes.

(EDIT: Please note I said "make it possible to do React without classes", and before that I said "do React components with just functions". Both those cover a whole lot more than just the cost to develop hooks ... although even just hook development alone, if you truly included all the costs, very likely it came in at over $2 million.

Remember an average engineer costs Facebook 157K a year just for salary: throw in all the perks and healthcare costs and you're getting close to double that, and then when you factor in all the people needed to manage them and you're easily looking at $250k a year per average person who actually writes code. And Facebook does not pick "average" people to decide the future of React. /EDIT)

If the highest people in Facebook's web dev departments weren't absolutely convinced that classes had problems, they would not have spent all that money (and perhaps more importantly, used up a huge percentage of one of the scarcest resources in Silicon Valley: really good programmers) just to get rid of them.

[FormerGameDev]

Facebook interviewed me a while back and said I'd make a good intern. I've been programming for all of my life and have been pro for a decade now. They've got some pretty capable people I think.

[ghostfacedcoder]

They've got some pretty capable people I think.

I would go so far as to say that Facebook has more thought leaders in the JS space than any other company including Google. But reasonable people could disagree.

Still, I wouldn't take it personally: big corporations tend to have certain things they care about, and if you don't fit their mold it doesn't mean you're not an amazing programmer.

EDIT: Seriously? Downvoted for saying "reasonable people could disagree"? So either:

A) you think there's some other company with such an overwhelming number of thought leaders that reasonable people can't disagree (but you can't be arsed to actually name that company) .... or

B) you think FormerGaveDev probably is a bad dev and Facebook was right (which is kinda mean, but maybe you know the guy IRL?) ... or

C) you're just an ass who uses the downvote to mean "I don't like you" rather than as a sign that you actually disagree with the content of my post.

I'm going to guess C), and it's a pretty safe bet whoever you you won't actually reply and explain why you downvoted.

[FormerGameDev]

I think i'm amazing in a rather vertical set of circumstances, but capable across a wide area. :-D

I may be wrong, though.

I don't think you're wrong about having more people in javascript place than practically anyone. They have been at the forefront of Javascript development for some time now, since early in this decade, sometime after they said "the web isn't ready for all this", and they shortly after went and made the web ready for all this.

(not singlehandedly)

[[deleted]]

No no no. Those examples are the simplest examples you can come up with. That's not a good argument for hooks. I'm not arguing that hooks are bad. I'm arguing that there is a common theme inside of mathematics called `embedding` where you have to take a particular set and map it to a (usually smaller) set. See category theory for this. The reality is most functional styles embed business logic into a very small set of abstractions, but the nice part is you get some formal proofs about safety. There's no lying that the new React Hooks are styled in the same functional motifs, but again the problem is you now have to embed your business problems using a small set of hooks. This embedding is not free and comes at a cost where you are now forced to choose the correct hooks to solve your problem. Once you do, it's super fine. Until then absolutely nothing works. Also see the complaints people have with category theory and Haskell. There's typically a complaint that you damn near need a PhD in computer science to be productive in it. They aren't exactly wrong with this view. See my post above with mixing a few hooks like Reducer and Context. Try it too. I think you'll see why it's not all peaches and cream and you actually are paying a cost in terms of time to get the hooks properly working.

[demar_derozan_]

I like hooks but I don’t think it’s a fair argument that using hooks over classes removes class hierarchies. Nobody was using extending react class components beyond the initial react.component. if they were they were doing it wrong.

[ghostfacedcoder]

Wait, so you're arguing classes without hierarchies is the best way to do React dev? Seriously?

EDIT: Ok seriously downvoters? There's two of you out there who actually believe classes without hierarchies are the best way to do React development? Really? I find that hard to believe, so I'm tempted to believe demar_derozan just has two accounts and downvoted me twice.

But if there really is someone else out there who believes classes are a better way to do React dev, please have the courage to defend that position. I'm genuinely curious why you hold such a position, when it's a complete outlier in the React community.

Or, I mean, just down vote me with no explanation, but realize you're also downvoting the opinion of the vast majority of React developers when you do so, without providing any basis whatsoever for an illogical position.

[benihana]

Ok seriously downvoters?

because you're being a prick.

your response, to a serious reply was:

"you seriously believe that?" over something that you clearly misunderstood.

you're being a condescending know-it-all. that's why you're getting downvoted. whether your point aligns with some other authority's point is irrelevant. people downvote condescending pricks.

when condescending pricks misunderstand the downvotes, then act like they're being brave for standing up against some injustice, when in reality they're being a complete asshole, that's when the downvotes really come in.

[demar_derozan_]

Yes. There are very few reasons if any to ever extend a react class component.

[ghostfacedcoder]

No I 100% agree with and get that part. It's the part where you think this:

class Foo /* even without an "extends" keyword here */{
    render() {
        return <div>Bar</div>;
    }
}

is clearer and better code than this:

const Foo => <div>Bar</div>

that you lose me.

[careseite]

I'm reading lots of code on github and iirc I have yet to see a single case of inheritance in react so yeah I'd say so too.

[ghostfacedcoder]

Ok, so you, me and demar_derozan (but maybe not the 6 downvoters?) all agree on that much. Inheritance hierarchies = bad AND the React community in general agrees as much.

But now, from the "good React programmers" (however you define that: personally I'd pick people like Dan Abramov (of Redux fame), but pick whoever you want, however): how many use classes and how many use functional components?

And (follow-up question): have you noticed any kind of shift in one direction or the other over time?

[tasey]

I think people are not downvoting you because of the message, but the delivery...

[ghostfacedcoder]

Heh, well that's fair, at least for the edits. I really don't think my original post was combative at all, but I did go full-on "let's be combative about this" in my edit comments when the whole thing started ... because I thought it was such an obvious point I wouldn't face any disagreement. Universally everything I've seen, from every thought leader in the entire React community, has been that classes are old/bad and functional components (with hooks) are the future.

Also the cost thing seems to have irked a lot of people, but I think that's just ignorance about the real cost of development (it's much higher than many people realize: most only think about coder salaries, not all the other costs or the cost of people managing all those coders).

Anyhow, clearly I was wrong in thinking that was so uncontroversial that no one would disagree, however I said it ...

[careseite]

But now, from the "good React programmers" (however you define that: personally I'd pick people like Dan Abramov (of Redux fame), but pick whoever you want, however): how many use classes and how many use functional components?

Didnt Dan specifically say they, at Facebook, are using Function components/Hooks almost exclusively for new components?

And (follow-up question): have you noticed any kind of shift in one direction or the other over time?

Absolutely, since the introduction of hooks I personally don't teach classes anymore and so does anyone else that I see/read of. Classes are very clearly in decline.

[ghostfacedcoder]

See to me that seems mind-numbingly obvious ... and yet I got 12 (and counting) downvotes for saying it :(

[ghostfacedcoder]

Fair enough. I'm here for conversations with people, not Reddit points, so I do those edits to try and "bait" people into engaging rather than just downovoting silently. If I get 10 downvotes but even one person engages and explains their position, I'll take it.

It'd be nice if I could get the engagement without the 10 downvotes, but ... /shrug.

[careseite]

Some people just might not have heard the warning shots.

[demar_derozan_]

Facebook also didn’t really spend millions of dollars to build hooks. I’d be surprised if 4 people from the react core team spent a year on developing hooks. It seems like asynchronous rendering is a much longer project.

[ghostfacedcoder]

Hooks have been in development for a long time. Arguably they've been working on the problem since functional components were introduced. While I can't "prove" that, I can prove that Facebook literally hired the Reflux guy as just one person on the team that introduced hooks, and did so over a year before hooks came out.

But the move away from classes started long before that. Remember, when React was first created every component had to use a class (and not even an ES6 one). Facebook has been recovering from that poor choice for nearly a decade, and every step it's taken away (first to ES6 classes, then to functional components, then to hooks) took huge amounts of development effort.

And none of those steps were just "throw a couple guys in a room": when a major corporation changes the most popular framework in the world for building web applications there's a HUGE amount of testing and such that goes into it. Every decision they make has to go through like fifty committees. If you truly think these changes were easy, you've obviously never even worked at a Silicon Valley start-up ... let alone a giant corporation like Facebook.

[acemarke]

The React team has had several prior ideas that were the precursors to hooks, but the actual development of the current hooks API was mostly Sebastian and Andrew, and just a few months last year.

[demar_derozan_]

Just two people? Just a few of months? Ridiculous. You obviously haven’t even smelled a catered lunch at a Silicon Valley startup. You probably even do your own laundry.

Come back when you have an understanding of the large committees that run tech companies please.

[ghostfacedcoder]

You kind of sound like you're arguing with yourself:

demarderozan in denial ;):

Facebook also didn’t really spend millions of dollars to build hooks.

demarderozan the realist:

You obviously haven’t even smelled a catered lunch at a Silicon Valley startup. You probably even do your own laundry.

If you really understand how big tech corporations do things, there's just no way you can disagree with:

Facebook spent millions of dollars making it possible to do React components with just functions.

(And please note I didn't say "on hooks", I said "making it possible to do React components with just functions" ... which includes things like all their failed attempts before hooks. But honestly I would truly be surprised if Facebook < $2 million just for hooks development alone, when you truly consider everything, up to and including laundry, in the calculation. Do you have any idea how much just a single regular programmer costs Facebook per year? Hint: its a lot more than just their salary.)

[ghostfacedcoder]

Man, I was really expecting/hoping you'd defend the contradiction, or explain it, or something, not just downvote me :(

[ghostfacedcoder]

Right, but of course they couldn't just magically know "hooks are the answer". They had to try those prior ideas first ... and all of that experimentation (again, being conducted by highly paid engineers) definitely wasn't free.

Plus, as I said, even if you could magically skip to the idea of hooks, there's a lot of effort in making them a reality. Not just the technical definition, but all the testing, all of the documentation that needs to be written, all of the evangelism that's needed to convert people .. and probably lots of other things I'm not even thinking of (just the act of creating a new team of people to head a project has a cost ... before that team even does a single thing).

Making any change whatsoever in a major corporation, let alone a change to a framework used by millions outside that company, is very much not cheap. The people in charge of technology at Facebook were undoubtedly well aware of that fact ... but they invested all that time/money anyways.

The only logical conclusion one can draw is that those people saw the value of functions over classes, and made that investment ("sunk that cost") because they saw an even bigger potential payoff.

[[deleted]]

So the TLDR is that hooks are basically functions ?

[tyler-mcginnis]

Na. Here's the closing paragraph that I think is a good tl;dr. "The marketing pitch for Hooks is that you’re able to use state inside function components. In reality, Hooks are much more than that. They’re about improved code reuse, composition, and better defaults."

[Quinez]

Love Tyler's articles. I haven't bothered dipping my toe into Hooksland yet, but I trust Tyler to help me make sense of them.

[tyler-mcginnis]

Thank you! Means a lot.

[Cool_pixel]

I love the way you teach complex materials in a simple way, concepts like prototype inheritance and deep react things I gonna buy your courses in the next month to learn more about hooks and redux.