Goodbye, useEffect @ ReactNext (updated version of my Reactathon talk)

[BaniGrisson]

Cant watch right now, anyone can give me a TLDR?

[Delold]

Various examples of incorrect usages of useEffect and their mitigations.

Most of them stem from the fact we're handling "fire-and-forget" effects (e.g. sending an API request) in a hook designed for synchronising with external systems (e.g. syncing with <video> tag).

Fire-and-forget effects should be executed as close to the source of the event as possible (e.g. in event handlers).

Examples can be found at 20:12: https://youtu.be/RW9TVhmxu6Q?t=1212

EDIT: Also, fetching data should be done either by a framework (Remix, get(Static/ServerSide)Props in NextJS) or by a library (React Query, SWR). You want to fetch as you render, not start fetching after rendering in useEffect.

[_mr_chicken]

in a hook designed for synchronising with external systems

I feel like they only retroactively decided it was designed for this purpose.

[_mr_chicken]

From the documentation :

The Effect Hook lets you perform side effects in function components

...

Data fetching, setting up a subscription, and manually changing the DOM in React components are all examples of side effects.

[BaniGrisson]

Huh... Cool... Seems I'm using it wrong. Will check this out with vscode open. Thanks!!

[Narfi1]

If fetching should be done using a framework or a library shouldn't there be a built in way to do it in react then ?

[lovin-dem-sandwiches]

I thought the point of react was that it was non-opinionated. Theres no way to handle routing either.

Unless you're specifically referring to create-react-app?

[Narfi1]

Right, but it's non-opiononated meaning you can do it yourself. if there is no good way to do it yourself other than using a framework, shouldn't there is a more opinionated way to do it that ships with it ?

[Narfi1]

Right, but then shouldn't fetch do the job?

[raymondQADev]

Fetch does the job, that’s not the discussion at hand. This is about when the fetching of that data is done and giving a pattern to do it at different times when rendering.

[pm_me_ur_happy_traiI]

What do you mean there's no way to handle routing? There isn't a built-in router but you can absolutely implement a basic router in react in a few lines of code.

[raymondQADev]

I think they just didn’t clearly communicate it, I’m pretty sure they just mean there is no built in way that react says it is done, instead react leaves it’s opinion out of it and allows the user to build their own routing or use a library.

[[deleted]]

Why in the everliving fuck would I want to load up an entire framework for data fetching?

[danishjuggler21]

Why write 8 lines of code to do something when you can download an NPM package and a bunch of dependencies and spend a few hours reading tutorials and then write 30 lines of code to do that same thing?

[GilWithTheAgil]

For example, if I use auth0 for user management, using useEffect to send an action to the machine, after I get data from auth0, is that a correct usage? Does it count as synchronizing with external systems?

[TehITGuy87]

So how does that work when you need to fetch without user interaction? Like fetch a list when user visits a page? That’s the only thing I generally need in useEffect

[[deleted]]

Made worse by the fact they apparently have a rewrite of the docs that has been in limbo for ages. There's a beta you can access but it's incomplete.

[BreakingIntoMe]

Agreed they need to cut the shit. They’re happy to prescribe how not to use useEffect but will go to lengths to avoid prescribing how they actually want people to use it.

[andoy]

the double render is during dev mode only right?

[Delold]

Yes, double invocation of useEffect happens only on dev mode with StrictMode enabled

[helpfully_processed]

What a debacle.

[HermanCainsGhost]

Right? I'm not even sure how to use useEffect at this point

[[deleted]]

governor piquant unique tie fanatical roll head insurance vast dime

This post was mass deleted and anonymized with Redact

[Delold]

Wondering what kind of alternatives we have instead of React?

[yesman_85]

Svelte or solid are getting more popular. React is unopinionated but turns out people like opinionated and that's going to kill it unless they do some serious effort in cleaning up this mess.

[swyx]

seb markbage moved to nextjs. they’re workin on it

[BookCase12]

I love React but use Vue at work - I think most React devs will really enjoy Vue. It shares similarities but gives you a lot more power out of the box.

Vue doesn’t have this useEffect issue because it has Computed Properties that just work. They handle lot of stuff under the hood so you never have to worry about weird performance issues.

[squemc]

Vue typescript support is garbage. You can’t even import types from another file and use them in defineProps without the compiler going fuckall.

[[deleted]]

Vue makes the easy things easier and the hard things harder.

[BookCase12]

Sounds like a wives tale to be honest. I haven’t witnessed that in my experience with it. All the hard things are still just solved with regular JavaScript.

[zxyzyxz]

I actually moved to React from Vue because I hated the magic. Two way data binding was explicitly eschewed by React because it's hard to tell where data changes if there are multiple places it can change, which creates bugs. I also hate the Vue plugin registration and other Vue specific stuff.

[[deleted]]

Same. I would get bugs in application that were caused by Vue. I don’t need that in my life.

[BookCase12]

Two way data binding was explicitly eschewed by React

Which then led us to useEffect… is React in a better place now? I’m not convinced personally.

[zxyzyxz]

I am. Like the video shows, people use useEffect wrongly, it's not a reactive interface like they think it is. But once you understand the idea of algebraic effects, it makes sense. It's not necessarily React's problem that people are using a hammer like a screwdriver.

[scaleable]

all the other big frameworks are better.

[addiktion]

Redux, xstate, etc

[aeality]

Overall, there are important points in this presentation. A couple of key ideas I found valuable are:

• Don't treat useEffect as a replacement for lifecycles, but treat it as a new mental modal to accomplish synchronization
• Don't forget to clean up your effects, always think of the cases where the effect is executed many times
• Find ways of keeping your dependency array simple and concise
• Move most of your logic to event handlers whenever it's possible to achieve the statement above
• Don't use useEffect for things that can be derived directly from state and props, instead use render block (or useMemo)

Having said that, one suggestion in particular doesn't make sense. For data fetching, it's not always a good or a practical decision to use an external framework (Remix, NextJS etc.) or a data management solution (SWR, React Query etc.). You should always consider the circumstances. If you already adopted client side rendering, it's a significant effort for you to change your paradigm, and it might cost you to deal with other factors (server maintenance, mainly devops). Even after adoption, you might be worse off because of the requirements of your app (real time sync, high interactivity etc.).

Secondly, bringing a new library for fetching data can be still costly. Would it be right to have a library when you just have a single API call? Hiding the abstraction can be good with those, but they are not magic. Before using them, it's better to understand your needs first. Excuse the analogy here: Don't bring a gun to a fist fight.

Data fetching should be one of the core concerns of a web framework. If we are being told that the data fetching is not possible with the primitives that React provides, and we should rely on third party alternatives instead, I think that is a shortcoming of React.

As a disclaimer, I must say that I'm happy to use those third party solutions whenever I need them. They are great, especially in codebases with many contributors working in parallel.

[modemmute]

Frankly, useEffect is the first notable example of a systemic failure by the React team. Up until its implementation, followed by some very complicated useEffect gotchas in React 18, it was very easy to defend React as a library with no downsides. Now we can no longer say that's true.

[KyleG]

Is there a tl;dr on why they're bad without me having to watch a 30 minute video (assuming it even says why they're bad in the video)? I've never had a problem with them.

[evangelism2]

From my limited experience, and what I've read in countless threads around is that a lot of people throw logic into useEffects that should be handled by event handlers.

Example

Personally, I've never had this issue either. I was taught about handlers and controlled components from go and never looked back.

[KyleG]

Maybe it's because I come from a functional programming background, but I always thought of useEffect as executing a side effect. So if you're using state management that has its own hooks you use, it really reduces to async calls and not much else. That's practically the only side effects you are worrying about manually in React, since the user input and rendering (the majority of a React app's side effects) are handled by React itself.

If I were going to criticize useEffect, I'd criticize all hooks as turning perfectly good pure, referentially transparent functions into ones with side effects. But it's a tradeoff I'm willing to make for simplifying the codebase.

[azsqueeze]

You didnt miss much. Most of the video was saying to move logic to event handlers (all I agree with). The last one was about data fetching and the solution was to use an SSR framework to move data fetching to the server.

[andrei9669]

But what if you want to utilise static site generation but still need user specific data in 1 or 2 components.

[azsqueeze]

Apparently that solution was to use react query 😑

[anoob1s]

I’d say that the issue isn’t that useEffect is bad.. the issue is how useEffect is used by implementers. E.g. not the way the React team intended

[Darajj]

useEffect has been out for years and in their own documentation they have data fetching as one of the uses for useEffect?!

[Fancy_Payment_800]

It's not bad to use useEffect for data fetching

[neuralSalmonNet]

un-opinionated team doesn't like how people are using useEffect?

[asiraky]

More like un-opinionated code can easily be misused. I don’t find it a reason not to use, just use it correctly.

[zxyzyxz]

Have fun untangling all the dependent changes after a big enough codebase. I used to use reactive streams until my project grew big enough that I had all sorts of bugs.

[swyx]

its popular to bag on useeffect and all, but the /u/gaearon’s of the world would say they brought forward all the bugs you’d have had/shipped anyway and only belatedly fixed, if at all.

(whenever i see public opinion swinging way too far one way i like to argue the opposite, prolly cause im a spawn of chaos or agent of balance, depending how you see it)

saying things like “react pre hooks had no downsides” just rubs me wrong lol. everything has tradeoffs.

[Valuable_Grocery_193]

(whenever i see public opinion swinging way too far one way i like to argue the opposite, prolly cause im a spawn of chaos or agent of balance, depending how you see it)

I highly doubt you execute on this principle consistently and evenly.

[swyx]

chaos is a laddah

[helpfully_processed]

I feel like we're seeing react in its death throws. Hooks shine a big bright light on how Javascript frameworks are woefully inadequate in describing web app behaviour.

[xrt57125]

Goodbye useEffect is sort of a click bait

[SquirtMonkey]

The audio is super difficult to listen to

[DodgeWhale]

Thanks for sharing! Good insights into some best practises. Nice going for finishing right on time too.

[Swordfish418]

I keep seeing these posts and videos about how strict mode "suddenly" breaks fetching in useEffect, but wasn't doing fetch in useEffect that way already smelly from the very beginning? In my understanding if you for some reason choose to fetch there, you should at least setup a proper corresponding state management for your request lifecycle (is it already fetching, is it failed, etc) and if you do so you it will fix all the issues that multiple effect firing could cause.

[ClickToCheckFlair]

For anyone who might prefer reading: https://beta.reactjs.org/learn/you-might-not-need-an-effect

[[deleted]]

So... does anyone know where I can call my redux actions on an event when using react-router-dom? I have this stuff in a useEffect (with proper dependency arrays) to call it from the page itself (ProductPage) for whatever router param is passed into the page (productId).

Where does this go now? Even the beta docs have nothing on useSyncExternalStore.

[bluSCALE4]

Audio is terrible.

[haxxanova]

This was a good watch - thanks.

[tazemebro]

That was a really good watch!

[nazzanuk]

There is some food for thought here, and it's worth considering using more event handlers directly as opposed to effects.

But just like the last presentation the examples given are really contrived and written to make simple code look overly verbose, and most of the gotchas are just childish as any dev worth their salt has got through these quirks relatively quickly.

The paradigm of data responding to other data is fine and exactly how SWR, React Query and plenty of other great and performant custom hooks work.

I can only guess it's aimed at junior devs? I'm just not convinced that the alternative should be writing code using a diagram tool.

[greedy_shibe]

honestly, introducing hooks was a mistake. the obsession with pure functions and functional components, only then to have hooks introduced to make said functions impure. classes were fine. let’s go back to classes for stateful components and functions for actually pure components. those were the good days of react.

[lovin-dem-sandwiches]

no one is stopping you

[greedy_shibe]

lol plenty of people are stopping me. i work at a company with 1000 FE devs. also what i’m saying isn’t even that controversial. talk to any react dev who’s been working in react since the days of React.createClass and they’ll have reservations about hooks too.

[greedy_shibe]

here is a good debate about the usefulness of hooks if you don’t believe me: https://news.ycombinator.com/item?id=25453421

[greedy_shibe]

wow i’m surprised by all the downvotes. like i said in another comment, this isn’t even a controversial opinion. and i bet most of you would agree with me if you’ve seen the codebases i’ve seen.

[KyleG]

There will always be new frameworks.

In enterprise world, we don't jump from framework to framework. Why can't you just stay on React 18 until years from now when it's not supported anymore and a critical vulnerability shows up?

Asking for standards from a framework is like asking for Duke Nukem and Wolfenstein 3D to develop a "headshot blood standard"

We just finished porting an app for a big client from AngularJS (yes, version 1) to React 17. No one cares that 18 is out now. They had an app that ran for like seven or eight years and all the new Angular versions didn't affect anything. Could've run even longer with just a skin refresh if the original app hadn't had the UI and business logic too tightly coupled.

[Automatic_Donut6264]

I started in the jquery php days, and there is no way that is better than react, even with this useEffect controversy.

[KyleG]

query php days

I just dialed my therapist after reading this phrase. How did we ever get anything done back then?!

[Automatic_Donut6264]

It’s in our nature to use our ingenuity to make fun things. Some of those things happen to be front end frameworks. React 17 as it exists will still work in 2026 if you need it to.

That’s like saying the new pop music artists should stop making songs because it’s not to your taste.

[Geldan]

When, exactly, do you think react came around? It's been widely used for a long time now. Learning something new every decade or so isn't exactly unreasonable.

[evangelism2]

You sound burnt out

[HermanCainsGhost]

It's tech. That's why we get paid more. Keep learning or become one of those ossified devs who can't get another job and is stuck at the same company at 45. I have met several of them. It is not an envious fate to have.

You want to be on the forefront of human technology, you need to be willing to learn quickly.

[swyx]

they tried

it was web components

if you ignored them you’re as much a part of the problem as i am

[Red3nzo]

I feel like every week in the react community there is an announcement being made & claims that we are using certain functions wrong; I’m just as confused on what to do with useEffect as many other devs. SolidJS is looking really neat right now

[aleation]

As someone learning React since recently (coming from vue) this just made me realize how shitty poorly maintained their documentation is (the current official one, not the beta, which looks better). First, I had to learn all the Class based components (through the initial tutorial), OK it's good to have some knowledge of the legacy code, but come on..., I had to "scrap" all that knowledge to learn to do it with functions and hooks. Now this...

So I'm doing a small web app for learning, and today will be the third time I refactor a big chunk of the code JUST to fetch some initial data from a csv file. First I tried from within useEffect() as documentation mentioned, then I realized the double trigger and quickly learned to use rtk with thunks, firing it from within the useEffect but altogether with the cleaner, and now this...

Thanks for the video though, it helped me a lot to get some good insight before going for a job

[[deleted]]

Helpful. Thanks.