Hacker News Reader

Comment by ervine | Hacker News Reader

I'll never understand the "hooks are bad" people. I don't find useEffect confusing, creating custom hooks is a breeze, life is so much better than old class components.

When I read complaints about hooks I'm either missing something fundamental about why they're bad, or the people complaining are missing it.

View on HN

Some people find the mental model to be very confusing. I've been writing hooks for years so intuitively, the behavior has sunk in. But I still admit that it's mind bending to try and understand how it actually works. The original commenter is absolutely correct that it diverges from both functional and OOP, and while that's not necessarily a bad thing, it's reasonable for people to consider it a net negative.

Whats the beat resource for the mental model?

There was an article I read, maybe 3-ish years ago, that explained it very well. It had you actually build a hook from scratch (not a custom hook, like actually implementing hook-like behavior into JavaScript). It was great. I just tried looking it up but couldn't find it, if anyone knows what I'm talking about please link here.

Following in care you remember / find it.

Any chance it was https://pomb.us/build-your-own-react/? You can't really have hooks without building an entire framework, because the framework has to have the preserve the execution context between renderings.

"useEffect" itself is not what is confusing. What's confusing is when you have many dozens of components with effects all loading state asynchronously. Some of them might even be executing callbacks passed as props from parent components. Oh, and then those effects sometimes re-execute when the effects of parent components complete and pass down updated props! It actually reminds me of programming VHDL.

And that's why using effects for such tasks is a huge anti pattern.

https://react.dev/learn/you-might-not-need-an-effect

The problem is you literally need to use effects to make api requests or access browser apis. You can't get away from it. Maybe you can try and tame the complexity by centralizing this logic as a small team but if the team gets big enough it's fruitless.

You're right, but I haven't touched a React project in ages that wasn't using a fetch library of some kind that give you hooks.

Cause you're inevitably gonna want to track loading state, error state, refetch on error, revalidate etc etc.

swr or tanstack-query are great and remove the need for useEffects for API requests. For sure they come with their own overhead, but there isn't getting away from the complexity of handling API requests and all the possible paths that can happen.

Isn't useSyncExternalStore the recommended hook for API requests? And for making API requests I think most people recommend using a library. React-query, RTK or swr for example.

For accessing browser apis useEffects are the way to go, but those are usually extremely easy to understand in my experience. Or just use a library that provides the needed functionality.

Per the blog post announcing it, it's not recommended that you use that hook directly, only in libraries:

> useSyncExternalStore is intended to be used by libraries, not application code.

https://react.dev/blog/2022/03/29/react-v18#usesyncexternals...

I know. So either use an existing library or build your own. But don't useEffect instead.

Yeah, just noting that link for context (I don’t think it’s documented on the hook’s own page?)

> The problem is you literally need to use effects to make api requests

No. Wtf? Don't do that. Never do that. Effects are for legacy DOM manipulation (and ad-hoc use of browser apis). Pretty much nothing else. Who tampers with states and data in useEffect is hellbent on creating spaghetti.

I assume your suggestion here is just to embrace a framework for data fetching and try not to think too hard about how they in turn implement it?

Can't really fault developers for falling into this useEffect trap when even the official docs show that data fetching is indeed handled via useEffect[1], while at the same trying to yell at the reader to "NOT TRY THIS AT HOME" and just go use a framework because it's such a complex problem... which naturally just creates more questions than answers for the poor developer trying to understand how it all works.

[1] https://react.dev/learn/you-might-not-need-an-effect#fetchin...

Uhh... That's terrible piece of docs. They don't even cancel stale fetches, just ignore the recieved responses. They don't debounce anything.

There are so many things about syncing data between the client and the server that this section of the docs should just say "Don't", use Apollo or Redux or whetever. React is UI library, for data you need data library or at least general state handling library. Quick and dirty will bite you tenfold.

If you have dozens of components with dozens of uncontrolled side effects executing in unpredictable order, then nothing is going to help you until you get those effects under control. It'll still be bad architecture with or without hooks.

> It'll still be bad architecture with or without hooks

The companies I've worked with had hundreds of engineers contributing to the react codebases and people are just trying to crank out features by the deadline. I'd rather just work with tools that don't require the usage of such obvious footguns. You can code solid-js and svelte and never use effects (even though they do offer them unfortunately).

Hundreds of developers all doing their own thing sounds like a recipe for said bad architecture.

> Hundreds of developers all doing their own thing sounds like a recipe for said bad architecture

This is the how the majority of tech companies operate.

> but I know better than to single out the tool for every judgment on design.

I disagree, most react developers are not even aware of this massive foot gun. I do blame tools for problems that are completely avoided by other tools, we can just consider this a difference in philosophy but I prefer to use tools that make as many types of mistakes impossible as they can.

From my experience (picked up react when it came out) hooks are not objectively better than class components in a standard web app. In the more reactive scenarios hooks are great, and your app is already complex and in its own world of mental models.

Hooks enable complex patterns too easily and I think this causes a lot of breakdown in what would otherwise be simple applications.

the problem with useEffect is how much it gets used when it doesn’t have to be

its overuse makes it evident that hooks (or React in general) is poorly understood

As someone who was into higher order components but left front end work before hooks were a thing, I’m wondering how the programming experiences are different are different between the two. It seems to me like more or less the same thing but hooks have more magic? Is it just a syntactic difference or are hooks a paradigm shift even further than HOC?

Yeah I never found them difficult and they’re making my life so much easier

Curious what specifically about them is difficult or hard to understand?

Reply on news.ycombinator.com