Item — HN Reader

> 5 straightforward hooks

`useEffect` is straightforward? Cloudflare recently (like, literally 4 days ago)[1] had a pretty big outage because of the improper use of `useEffect` (surprise, surprise, it was the dependency array), a hook so infamous if you search "When should I use `useEffect`" you'll get approximately 9 trillion hits, with nearly all of them telling you something different, including Dan Abramov himself having to chip in with multiple blog posts telling people to NOT use it because of how much of a dumpster fire of a API it is.

[1] https://blog.cloudflare.com/deep-dive-into-cloudflares-sept-...

2 comments

Well, that is really embarrassing for Cloudflare... A recursion in a side-effect via dependencies is a rookie mistake, it's hard to imagine it could slip into production with a proper due process. Maybe they should stop vibe-coding and deploying things to production without any tests or review?

If after nearly a decade swarms of people are still making the exact same mistakes with how they use a specific method exposed by the library, then the problem isn't with the hundreds/thousands of people making the mistake, the design of the method is broken. This type of issue simply does not exist in Vue or Svelte even if people abuse watchers (which I've anecdotally noticed tends to happen from React devs writing Vue code).

Also I just want to point out again that Dan Abramov had to write an insanely long guide to using useEffect [1]. This piece is around 10k words explaining in-depth how useEffect works. That is insane for one of the fundamental, core methods exposed by a library.

[1] https://overreacted.io/a-complete-guide-to-useeffect/

You know for thousands of years people are still stepping on rake, the spikey part. And they get hit in their foreheads. The rake is lever by design, but I wouldn't say the problem is the rake.

I've spent more hours using rakes than `useEffect()`, but I've only had the problem with one of them.

A) exactly how many people in alk of history have ever actually done that?

B) rakes can't be changed to prevent that, software apis can.

Disagree about it being a rookie mistake. In the simple case, yes. But consider data used by an effect could travel all the way from root to the max depth of your tree with any component along the way modifying it, potentially introducing unstable references. Maybe it worked when you tested. But later someone introduced a new component anywhere between data source and effect which modified the data before passing it on. That component may have used useMemo. So it looks ok, but it over fires.

You become reliant on all your ancestors doing the right thing, in every situation, forevermore. One mistake and unstable references cascade everywhere. The surface for introducing errors is huge, esp in a large, complex codebase. And we have no way to guarantee a stable reference.

>But consider data modified

This is why we never modify data but create new data. Data must be immutable. Strictly typed. Always in the form it is expected to be. Otherwise - crash immediatelly.

>But later someone introduced

This is why we write integration tests. Introducing anything without tests is only guesswork.

Sorry I should have been more precise. I don't mean mutation, but taking the data and producing a new (potentially unstable) reference to pass on. Mutating data in react results in under not over firing.

It is practically impossible to have full coverage of all code paths in integration tests, since there is a combinatorial explosion of paths. In a case where you have 3 components each with 3 paths you have 27 unique paths. And no app is that simple in practice. It gets out of hand quickly.

As a rookie with gray hair I completely agree :)

Javascript has warts, React has warts, Svelte has warts, Python has warts... It's easy to shoot yourself in the foot in any tech - it's leaky abstractions all the way down after all.

useEffect usage needs to die, yes. I don't think it's a case against React, given its age.

Otherwise, using React is straightforward. I started coding in it without reading any docs. As someone who used Dojo, prototype, ext.js, jQuery (+UI), Backbone.js, knockout (still has a special place), Mithril, the classic angular, vue (2), svelte, Marko and even Solid (I'm not totally sold on signals), React is the most straightforward by a mile.

Is it the most performant? Hell no. Is it the one with the least gotchas/warts? Nope. Concise? A giant no. Batteries included? It depends on what you're looking for...

But I can just be productive with it, and it makes sense.

A child who hasn't tasted other mom's food always say, my mom is the best cook in the world.

You saying you can be productive in react is just ironic. I just read it as, I can be employable using React.

My brain does this sometimes, sorry :) I meant to say, "I can just be productive immediately in React". Not going to edit though.

edit: also about the moms cooking analogy... With many of those libs/frameworks, I have much more experience with than react.

We need to determine which framework is most productive while suffering from Mommy brain.

You like jokes

Bro lists like 8 different moms whose food he has, then says he likes react-moms food, and you make it sound like that's the only thing he's ever had. Did you even read the comment you replied to?