You might not need an effect

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

by lawrencechen • 3 years ago

242 240 3 years ago

yieldcrv• 3 years ago

huh.

well I’m lost then.

glad they’re writing this up. I come to react after hooks was introduced, and have been kind of put on a pedestal for not needing to “learn hooks” since thats all I know, for React.

still looks like I need to relearn something.

aeroaero3• 3 years ago

This page should be mandatory reading for any dev working in react. The biggest mistake I see with devs of all levels is over use of effects.

This seems to be especially bad for anyone who originally worked with class components. The mental modal shift was large and people tried to fit their understanding of lifecycle methods into hooks, attempting to replicate similar behaviour. The docs at the time did a poor job of explaining why this was a bad idea.

brundolf2• 3 years ago

100%. Effects are an escape-hatch, and it's really common for people not to treat them that way. All of the new docs are gold, but if I could only pick one to recommend that every React developer read, it would be this one

cjonas• 3 years ago

Second is abuse of useState for calculated values

Rapzid8• 3 years ago

Effects are an escape hatch from the React paradigm

Hooks are overused in general. But I really disagree with this sentiment. Its useEffect and useLayoutEffect(okay useInsertionEffect too) hooks are THE mechanism they CHOSE to expose component life cycle. It's not an escape from React paradigm, it IS the paradigm. Function component React would be useless without these hooks; the DOM is an external system!

I'm really just put off by the React documentation in general. It feels like it's aimed at junior devs working on FE assembly lines and they want to keep the blinders on them. "Pay no attention to the man behind the curtain!".

robertoandred10• 3 years ago

Or maybe you shouldn’t be thinking in terms of a “component lifecycle”.

lloydatkinson3• 3 years ago

Exactly - OP is perpetuating bad explanations.

https://epicreact.dev/myths-about-useeffect/#:~:text=Here%27...

the_gipsy13• 3 years ago

How do you handle route changes and data fetching, then? Back to Redux?

kqr2• 3 years ago

Counterpoint: I'm not a junior dev in general, but a couple of years ago I did my first project involving React. I came back to it a year later and was able to refactor away much hook usage and make components pure. It greatly simplified the codebase and I wish the documentation would have been more insistent on this back when I used it, so I didn't have to earn the experience on my own.

I guess the redeeming point is that hook usage is usually easy to refactor out, unless it's permeated your architecture somehow.

Rapzid8• 3 years ago

I agree with everything your saying I just disagree with the communication; well and I believe the line I quoted to be utter bollocks.

Dealt with projects that had evolved(devolved?) into hook monstrosities. 20-30 hooks in god components each with n-layers of "custom" hooks each permeated with useEffects and useStates chaining off each other causing a rats nest of render loops and maddening re-render puzzles.. It's awful.

I'm anti-hook in general and I use them very sparingly. But they, the effect hooks, are integral to React and need to be used to build the vast majority of anything interesting. People will need to use them or use something written by somebody else that used them. To me that's not an "escape hatch" but fundamental to the libraries usefulness.

ihateolives3• 3 years ago

I guess the redeeming point is that hook usage is usually easy to refactor out

Yes, but now imagine that you could've done it more or less correct in the first try. Refactors happen, but needing the refactor after it took 2 years for best practices to sink in? I don't think it's an endorsment for the hooks.

I refactored my old React app from classes to hooks when hooks became fashionable. Few years later I'm still sure that it's a mess and I've used hooks wrong. Am I itching to refactor again? No way. I let it rot some more, perhaps React will take another sharp turn and I'll save myself time doing it twice.

strken• 3 years ago

Calling things an "escape hatch" (not used in normal operation) when they're more like an airlock (used during normal operation to access a dangerous area) is an irritating language choice.

pcthrowaway• 3 years ago

Beautifully put, they really are more of an airlock

the_gipsy13• 3 years ago

Yes! It helps no one. I think that some authors are just infatuated with FP and can't get over the fact that only the most trivial widget is pure in React.

ricardobayes3• 3 years ago

True, this is some really unfortunate wording. Since functional components don't have lifecycle methods anymore, relying on useEffects is pretty much the only way to subscribe to a prop change and render/handle its change. Now according to the new docs, advocating to go "local variables" way feels a bit non-React to me, actually.

MrPatan5• 3 years ago

What do you mean? When props change the component re-renders, doesn't it?

dgb233• 3 years ago

The wording is unfortunate as I said in another discussion.

useEffect is not an escape hatch, it’s a fundamental building block.

The point of articles like these is that people use useEffect when they don’t need them. So it’s robust advice in that regard!

But you’re always going to use it, directly or indirectly.

For example if you’re doing anything interesting with your layout that CSS can’t exprees, which is fairly often, you’re going to need useEffect in order to read the DOM and calculate your layout.

bakugo• 3 years ago

I'm really just put off by the React documentation in general. It feels like it's aimed at junior devs working on FE assembly lines and they want to keep the blinders on them. "Pay no attention to the man behind the curtain!".

Is this a problem specific to the documentation, or does it apply to React in general (or at least functional components)? Because I feel like it's the latter.

brundolf2• 3 years ago

hooks are THE mechanism they CHOSE to expose component life cycle

Yes, and component lifecycle itself is an escape-hatch (or airlock, or whatever).

Function component React would be useless without these hooks; the DOM is an external system!

It is an external system, but most fundamental idea of React is that you don't have to write your own effects or lifecycle logic for updating the DOM (the great majority of the time). That's the whole point. The way React lets you update the DOM without using a side-effects programming model most of the time is the reason people use it. Instead of writing side-effects toward the DOM, you write a unidirectional flow of values derived from other values which bottoms-out in DOM (which React then "affects" for you). Custom effects are (mostly) for the situations where you're updating an external system that isn't the DOM.

The biggest problems in my experience come when effects become a part of the core domain logic. That's where things get really hard to follow, and that's the most important thing to discourage. Effects should be reserved for the boundary between the app and the outside world (minus normal DOM updates).

Mavvie• 3 years ago

I agree completely. And that's what I liked about this article: it taught me what effects aren't for. I had been using most of the anti patterns in the article (especially using effects to sync props and state with each other), and it showed me a better way to do all these things.

owenpalmer• 3 years ago

You might not need React

lloydatkinson3• 3 years ago

You might not need to write drivel comments too

zach_garwood• 3 years ago

You should lead by example.

parasti• 3 years ago

Weirdly disappointed, turns out I still need useEffect because I've been using it as intended.

eyelidlessness• 3 years ago

You might not not need an effect.

erwinh• 3 years ago

Wait so in the prop change example they are now recommending that you can update state during a component render?

_thisdot• 3 years ago

Far as I see they aren't. They're recommending you don't use unnecessary state. From the example, if you have state for `firstName` and `lastName`, you don't need another state for `fullName`. Just calculate it during the render as `'${firstName} ${lastName}'`

foota2• 3 years ago

They're referring to https://react.dev/learn/you-might-not-need-an-effect#adjusti..., where they literally call setFoor in the render method.

I guess this makes sense, but it's weird after all the "never do anything stateful in render"

foota2• 3 years ago

Wow, that's really weird.

jannes• 3 years ago

Yes, and they explain it as well. Doing that leads to the component re-rendering immediately without rendering any child components.

This should be faster than useEffect which only executes after the entire render has been committed to the DOM.

aeroaero3• 3 years ago

Yep it can be a useful pattern, but it must be in a conditional to stop an infinite loop.

This useful guide points it out as well: https://blog.isquaredsoftware.com/2020/05/blogged-answers-a-...

idkwhoiam• 3 years ago

This caught me off guard. I've never seen this pattern anywhere including popular 3rd party React libs. Therefore it doesn't feel right but their explanation makes sense.

sickcodebruh4• 3 years ago

I found this one very surprising. I’ve operated for years with the understanding that side-effects should never ever occur within the render flow. Complicated as hooks are, I dread having to explain the nuances of this particular one to other React devs.

fabian2k• 3 years ago

Interesting Detail about this from Dan Abramov:

https://twitter.com/dan_abramov/status/1638773531881140224

fun fact: You Might Not Need an Effect was inspired by a little investigation. i spot-checked random 128 useEffect calls in the Meta codebase, classified them into several groups, and 59 out 128 were unnecessary.

My own experience, on a much more limited scale, is similar. Especially developers new to React tend to write more useEffects than actually necessary. These often add unnecessary complexity and make the component much harder to understand.

albert_e• 3 years ago

Sounds like this is more general pattern

I recently reviewed an architecture on AWS that has 5 services chained together to make information flow from source to target.

There was no justification for the middle three. The volume of data, loose coupling, native support for direct integration were all there to directly connect source to target.

Dextro• 3 years ago

I agree with this sentiment. I find that most developers seem to be stuck in thinking of their components as imperative. They expect to alter the state (dom) directly instead of describing the dom as a function of state (props).

Because of that, they quickly reach for the escape hatch that useEffect provides everytime they need to change something.

I genuinely don't know how to help my fellow team members grasp the basic concept of components better. It doesn't seem, to me, like it's something everyone gets eventually. I've actually seen far too many developers who just don't seem to get there even after long months working with component libraries.

As a side note: I don't get all the love for class components. All I remember from using them were the endless bugs because we somehow missed something on willUpdateProps or whatever. Class components could have worked but they always felt like the different life cycle methods were all cobbled together with little overall consistency (see Vue for an example of life cycle hooks done better, even if I have plenty of other gripes with Vue's design)

MrPatan5• 3 years ago

Indeed. React was a welcome innovation because it enabled V=f(S). That's it.

The vDom was fast enough that it made re-rendering your view on every state change possible.

Now you don't have to worry about rendering, you describe your components as pure functions and you're done with that side of things, now you "only" have to worry about the state of your app.

Seeing comments here wondering "How am I supposed to use jQuery with React otherwise?" is baffling and disheartening.

rusl1• 3 years ago

59 useless useEffect out of? I think the meta codebase could have thousands and thousands of useEffect. That's a poor argument from Dan

andrewingram6• 3 years ago

He looked at 128 random useEffect calls in the codebase, and determined that roughly 50% of them (59 calls out of 128) were unnecessary.

billllll• 3 years ago

IMO if you need a long doc like this pointing out the sharp edges, then I think you've done a poor job in designing the framework.

I love the terseness, reusability, and typing of React hooks, but hooks have too many weird edge cases (this article, dependency list, order of hooks, etc) versus class components, whose design was simple and elegant.

I'm just an old man yelling at clouds though, the terseness of stateful components defined in a function, plus simple typing with TS (no defining proptypes) is too appealing to me personally. Maybe I'll check out Solid next time, which seems to have less weird edge cases.

junon• 3 years ago

I've used Surplus for years and love it. Highly underrated framework. It's hooks, but designed properly, and consistently beats out almost all other frameworks performance-wise.

It's in need of a few upgrades though, namely a few edge cases in the old JSX parser (it was written before Acorn had good JSX support) but works pretty much perfectly still today.

ihateolives3• 3 years ago

It's hooks, but designed properly, and consistently beats out almost all other frameworks performance-wise.

Performance is nowadays one of my last concerns with frameworks. They're all snappy enough except for corner cases. More important is whether there are standard ways of doing things vs everyone inventing their own. Our company uses Vue which has standard lifecycle methods, standard way of scoping CSS etc, officially endordsed store etc. Makes it much easier to bring people up to date when they're joining the projects.

bowsamic• 3 years ago

Really it is quite an amazing situation. The conceptually clunky but easy to understand class components vs the conceptually pure but esoteric hooks. Even at the time the React dev team were putting in a lot of effort to say "you will get it soon, don't worry", because they already knew it was in many cases difficult to understand and use properly. That should have already been enough of a sign to not push it so hard.

orangepanda• 3 years ago

useEffect was designed to allow shooting yourself in the foot, in a good way. There's never a situation when react doesnt allow you to accomplish something - the page even a mentions of synchronising with jquery!

Whats the alternative you propose? Not allowing react to be used with any 3rd party libraries or access to browser apis?

justusw• 3 years ago

Sorry for the disgruntled snark in advance:

Heh, we already have that and it is called Elm.

By me, an Elm user until 0.18.

rawoke0836005• 3 years ago

useEffect was designed to allow shooting yourself in the foot, in a good way.

Ok... no... there is no good way to shoot yourself in the foot (metaphorically or real)

There's never a situation when react doesnt allow you to do something

That is EXACTLY what I DONT want from my framework:

MrPatan5• 3 years ago

Yes

rawoke0836005• 3 years ago

IMO if you need a long doc like this pointing out the sharp edges, then I think you've done a poor job in designing the framework.

x1000 upvotes.

One alternative is of course svelte, the unofficial-slogan (svelte) is/was that you can explain it to someone or learn it yourself in an afternoon.

Reminds me a lot of C++ vs Go in terms of Public/Private/XYZ

Go: To make a something public, start the var name with uppercase.

C++: To make things public read the Chapter on "Access Modifiers".

DavidPiper• 3 years ago

While I agree with your point, the example you gave feels like a straw man. Or at least, a separation of "sharp edges" and "long documentation needed".

Phrased differently:

Go: To make a something public, start the var name with uppercase.

C++: To make things public, type the word 'public'.

The Go pattern seems like more of a sharp edge than the C++ version, even though the C++ version might need more reading to learn.

the_gipsy13• 3 years ago

Go using casing for access is quick but is awful when you just want to change the access later on. It's not like writing `pub` before the var/field is suddenly javaland, see rust.

danielvaughn2• 3 years ago

I got up and running in Svelte in literally 5 minutes, and it blew me away. I just started building and referencing the docs along the way. But then...I ran into their reactive model, and spent an entire day trying to debug (what I thought was) a very simple problem. I can't recall the details but I remember it had something to do with the order of updates? It was super confusing. Moral of the story is that there are always trade-offs.

rozenmd• 3 years ago

Not all sharp edges are equal, the sharpest (according to % of traffic to my blog, anyway) seems to be race conditions (https://maxrozen.com/race-conditions-fetching-data-react-wit...), and that's not even unique to useEffect...

kristopolous3• 3 years ago

I've run into race conditions inside of react that has made me gobsmacked. I swear the thing must be written by fresh faced middle schoolers.

I'm so glad I don't have to deal with it anymore. After being in programming for over 20 years, I started making plans to exit the entire industry. Now I realize it was just react. That thing made me despise programming. I kept a virulent twitter journal of my time in react. It seems foreign to me now. Good! Example(s): https://twitter.com/SisNode/status/1458942812087414797 ... it made me pretty intolerant https://mobile.twitter.com/SisNode/status/143380932394827366...

The tweets in that account are like an insult comic does programming.

kobalsky• 3 years ago

looks like we've unknowingly avoided a lot of issues by using redux and sagas.

this model clicks so perfectly I still wonder why it's not the standard.

agumonkey• 3 years ago

There's a running in circle feel about react right now for me.

It's the same old OO (state+methods) vs FP (lexical scope + closures) thing, in the dom now.

A lot of react state libs are also tweaking around this idea.

Not long ago a jotai class made me see this.

    <Component />
    <Component />

these components use the same state defined in the source

so to avoid that

    <Provider>
        <Component />
    <Provider>
    <Component />

which now intercepts the state object creation to have two independent states. I have a feeling that soon we'll see

    <new class={Component} />

strange

wouldbecouldbe2• 3 years ago

IMO the simple old class & props was all that was needed. Lifecycle was much easier to understand, most reusability issues could be solved one way or another.

Most bugs I find in big react projects are either by using multiple useEffects in one component, and the other one with Saga. Also another "side effect" tool.

chrisweekly3• 3 years ago

Class component usage patterns where "lifecycle was much easier to understand" were inherently problematic though; they led to redundancy and verbosity, grouping unrelated code in a given lifecycle method and fragmenting otherwise-related code across disparate methods. Those deprecated lifecycle methods are overly imperative, with poor ergonomics. (Dan Abramov wrote a great post about these shortcomings; I'm on my phone or I'd try harder to dig up the bookmark).

Don't get me wrong, I have fond memories of using classes as bags of methods (esp with Mobx) and it took me a while to come around on hooks. But given your "most bugs... useEffect... and Saga" (does anyone still use Saga?), maybe the over/misuse of useEffect -- not hooks / FC more generally -- is the crux of the problems you've encountered. Which might even reinforce the OP (shrug). :)

TheCoelacanth2• 3 years ago

I used to frequently see people misuse componentDidMount/componentDidUpdate in every single way that is listed here.

There's really not that much difference.

davedx2• 3 years ago

No you're right, I completely agree with you. It's also very telling that there's also this very long article about useEffect dependencies: https://react.dev/learn/removing-effect-dependencies

useEffect and dependencies are the worst part of React at the moment.

The reason is, you do need to use effects, everywhere in your code, constantly. And dependencies, and the linter rule that goes with them, are nasty ergonomics, and hard to reason about.

The article I linked does explain it all quite well, and most devs I work with do understand the dependencies rules, but the rule still needs to be disabled often. Why?

Often the lint errors really are just wrong. Just like ChatGPT is often simply just wrong, no ifs or buts. For example: you have a callback function declared as an expression, that the useEffect hook calls. The linter will say "oh this is an expression, therefore it needs to be declared as a dependency". But it doesn't, because looking at the code as a human, you can immediately see the function never changes.

If you follow the linter, you will inevitably end up going down a destructive and unnecessary refactoring. You'll end up with unnecessary `useCallbacks` sprinkled everywhere that hurt readability for nothing. Often, you'll have to refactor the dependencies out of the component entirely, splitting one cohesive component into two, just to satisfy the linter out of an abundance of caution.

Junior devs will be confused. Senior devs will be frustrated. Every react codebase I've worked on has gagged this linter warning.

So how should this work?

It shouldn't be a a linter error in the first place. Linters should be used to enforce coding standards, not fix application bugs. I feel very strongly on this.

zarzavat• 3 years ago

The funny thing is that React already kind of has its own programming language: JSX. If they wanted to, they could add language features to support React. I expect that would be very controversial though.

Rapzid8• 3 years ago

There is a new experimental hook, useEffectEvent, whose only discernable functionality based on the documentation and information available is to quiet the linter. I'm not sure that's all it does since I haven't dug into the React source code, but that's what many are speculating.

cbovis2• 3 years ago

"For example: you have a callback function declared as an expression, that the useEffect hook calls. The linter will say "oh this is an expression, therefore it needs to be declared as a dependency". But it doesn't, because looking at the code as a human, you can immediately see the function never changes."

Can you elaborate on this? In my experience this isn't the case. If a function is declared outside of the component scope then it won't trigger a lint error. If it's defined within the component scope and not wrapped in useCallback then it does in fact change on every render and the lint error is being raised for good reason.

ly3xqhl8g9• 3 years ago

Reading sentences such as 'Effects are an escape hatch from the React paradigm.' in the official documentation in 2023 while writing React since 2015 makes one depressed and angry (deprangry?): then how are you supposed to use this 'library'. Luckily they provide a firstName/lastName example, because that's all we use React for, no?, login forms and hello world todos apps.

As with everything, if you want to make an apple pie, make a universe: after all, the mistake was mine, starting to use React in 2015 instead of making my own language/framework, mainly because what I have today is already a bunch of highly idiosyncratic React utilities. If there is one hope with the large language models hype is to finally be able to code against a true common interface (the HTML/CSS/JS specification), and do it anyway you please, translating on the fly any third-party dependency.

threatofrain• 3 years ago

Be warned that the state of docs is very weak, and that although the Solid team acknowledges this issue and are working on a beta¹ version of the docs, the effort really crawls along. It's also really hard to get help. Maybe there are many Solid lovers, but there aren't enough Solid intermediates to help prune the support forum. I attribute this to slow progress of the docs.

[1]: Note that this docs effort doesn't include SolidStart, which is a big bummer.

cbovis2• 3 years ago

I actually disagree here pretty heavily and think that this doc is due to the bar for competent developers going down in recent years (due to the rise in necessity for more developers of course). There's almost an expectation that powerful tooling should be dumbed down.

The entire doc is written around two common problems:

* You don’t need Effects to transform data for rendering * You don’t need Effects to handle user events

Both of these problems do not occur if you take the time to understand the tooling React gives you. The events point should be a given, that's just React 101 (and yet they have to spell it out to people...).

You don't end up using useEffect to transform props/state and generate new state if you understand that those things are just variables and you can instantiate new variables using them inside the scope of the component function.

"But that's inefficient because of how re-rendering works".

Great, you understand how re-rendering works but haven't gotten familiar with the useMemo hook. Come back when you've gotten familiar with the primitives available to you in React and how they can all work together in different ways, there's not that many of them!

This doc reads to me like a DIY store publishing an article about how you shouldn't hammer in screws even if it kinda seems like you could if you didn't take the time to understand hammers, screws, and nails. It's sad that it needs to exist but that's the current state of engineering.

Sammi6• 3 years ago

I have no idea what you just said :/

But I barely know React.

_heimdall2• 3 years ago

Your entire argument here is a shining example of how the growing complexity of react has raised the bar of skill for competence rather than being a victim of lowering the bar.

Think back to the webdev world before react. Was it really that the average dev was more competent, or that the tools of the day were in fact more simple to use? Sure there are more and less efficient ways to use jquery, but unlike react you didn't have to keep so much in your head at once while building a simple feature.

React was designed to be a UI component library. We keeping asking more of it and stuffing more and more complexity into react so that monolithic frameworks can be built with it. It was never designed with that goal in mind and is taking more and more complex features to try to keep that ship afloat.

jrsj• 3 years ago

Both of these problems do not occur if you take the time to understand the tooling React gives you.

Wait, there’s people in this industry who are taking the time to understand things before using them?

jve2• 3 years ago

It's sad that it needs to exist but that's the current state of engineering.

Wait, wait. I'm trying to make friends with React for less than a month and I do appreciate this article giving me some understanding about the primitives react gives me and when to use it (Or how you called it screws/nails)

I did understand more, but I'm left with a feeling I cannot follow the "flow" of the useEffect as I couldn't understand how can items !== prevItems EVER be true?

  // Better: Adjust the state while rendering
  const [prevItems, setPrevItems] = useState(items);
  if (items !== prevItems) {
    setPrevItems(items);
    setSelection(null);
  }

useState doesn't return immediatelly? Or does it cause immediate re-render? I kind of gathered from the article that all useState calls cause re-render whenever it encounters return.

cccybernetic• 3 years ago

yeah I agree with a most of this, but useEffect is still a shit show. It's nasty, and it sits in your code like an anvil, heavy and terse, it even looks like one, with it's lopsided dependency array. The semantics are so strange, and it's not even really for side-effects, more so for synchronizing state. And while I love React, it's not uncommon to see entire codebases where every function is wrapped in useCallback and useMemo, you know, "just in case".

cooperadymas• 3 years ago

and think that this doc is due to the bar for competent developers going down in recent years

"The tool isn't poorly designed, everybody is just too stupid to understand it."

randomdata• 3 years ago

There's almost an expectation that powerful tooling should be dumbed down.

Which is the problem here. The abstraction in question tries to dumb things down, but doesn't succeed in dumbing things down enough. As a consequence you get their weird middle ground where you can't access the gritty details an experienced programmer would want, but it doesn't hide the gritty details from the inexperienced programmer, ultimately serving no one. As usual, you can make it work, but it is a poor abstraction.

Hrun0• 3 years ago

I actually disagree here pretty heavily and think that this doc is due to the bar for competent developers going down in recent years (due to the rise in necessity for more developers of course).

This was a non-issue with class components.

data-abuse• 3 years ago

Overuse of useEffect is my number one pet peeve for juniors. I can't tell you how many times I have seen a total mess of manual data passing between 3 components with so many if..else cases to handle all the weird stuff.

I catch it in code review and show them that when you delete all of it without useEffects and useStates that it just works. Its an antipattern that turns the code into a giant ticking time bomb if you don't manage all of it out.

gspencley• 3 years ago

Part of the problem is that React was never a "framework" to begin with, but people treat it as if it is. React began its life as a view library for creating custom components. That initial design decision has permeated every attempt to make it more "framework-like."

In a traditional MVC-like paradigm, components would just be views. Discussions would be focused around keeping your components limited to view concerns while using other, non-view parts of the framework to drive things like API integration, business logic, state management, routing config and so on. Which is to say that you wouldn't have a need for "effects" at the component level in the first place since, by the time your data is ready for presentation and your components are initialized, all of that has already been done separately.

So yes, it is a design flaw with the "framework". One that came about by trying to morph what was, initially, a simple view library into something more "framework-like."

KronisLV• 3 years ago

I love the terseness, reusability, and typing of React hooks, but hooks have too many weird edge cases (this article, dependency list, order of hooks, etc) versus class components, whose design was simple and elegant.

You know, I kind of agree and personally prefer Vue (that does hooks better in some ways, as well as has a simple store solution called Pinia that's nice to use), but I have to say that these docs themselves are great.

Even if there is some awkwardness about using React and it needs some getting used to, to be able to use it effectively, I think these docs are definitely a step in the right direction and offer concrete examples! The code is mostly clear, the text explains everything bit by bit - we could use more of that in our industry for sure.

ttfkam2• 3 years ago

It's a sad state of things where React—even with hooks—is considered by some developers as "terse". It makes me wonder if we're all actually speaking the same language.

vbezhenar3• 3 years ago

One thing that I don't understand: why design useEffect api with dependencies array which does not get passed in the function?

If you ask me, I'd design it the following way:

  useEffect(f, {a, b, c});
  
  ...
  function f({a, b, c}) {
    ...
  }

Function f is supposed to be declared outside of render function.

This way you must specify all the dependencies. JavaScript will bite you with undefined value, TypeScript will bite you with compilation error. The drawback is that you'd need to pass setValue functions which are typically immutable, but I don't think that's a bad thing anyway.

pavlov• 3 years ago

"Function f is supposed to be declared outside of render function."

That's the cinch. To get the benefit of this proposed API design, the effect handler functions must be be outside of the render function so they can't capture any values other than the explicit dependencies. That's not a requirement you can enforce in JavaScript, so it would have to be a linter-level thing.

I think it would aesthetically run counter to the prevailing design of React functional components. For better and worse, it feels like the framework designers have made a substantial effort to contain a component inside a single function. With this design, you'd have the component and its effect handlers in the same parent scope even though the handlers are subordinate to the component.

rk06• 3 years ago

How would useEffect () access those dependencies? useEffect() them to determine if f() needs to run again or not.

slmjkdbtl• 3 years ago

Solid has very similar API, but much simpler concept (and of course performance), it's just a plain js signal library with some ui helper functions no dark magic, whereas react is the most framework framework out there.

mpweiher• 3 years ago

IMO if you need a long doc like this pointing out the sharp edges, then I think you've done a poor job in designing the framework

And it seems that the React maintainers don't understand their own system, in a sense.

That obviously sounds a bit weird, but as far as I can tell they seem to think that what makes React good is that it is "functional". And so when something isn't quite right, they "fix" it by making things more functional. And that seems to invariably make things worse. Rinse and repeat.

Hmmm...

What if the good part of React is that it is a reasonably decent UI widget framework for the web? And that the FP-ish nature is really more an implementation detail due to the way it is embedded into the web platform? And that this led to the happy accident of being able to write the UI as a procedure that structurally reflects the UI to be displayed?

rglover• 3 years ago

IMO if you need a long doc like this pointing out the sharp edges, then I think you've done a poor job in designing the framework.

Thank you. It's self-serving (mea culpa), but this is the exact reason I moved away from React and decided to build Joystick [1].

[1] https://github.com/cheatcode/joystick

schwartzworld• 3 years ago

The problem is that React was designed to allow you to use functional programming to express a UI that is a function of state. It might be obvious to experienced functional programmers not to sync internal state using effects in this way, in no small part because they understand what a side effect is already.

dependency list

This, again, is only confusing if you don't understand what an effect is for: syncing with systems external to React. How else would you say "do the thing when any of these change"?

order of hooks

I never understood why this was confusing for people. It takes 2 seconds to learn this rule, and your browser console will yell at you if you violate it.

oaxacaoaxaca• 3 years ago

Completely agree. Class components are so beautifully simple. Hooks have infuriating edge cases and are so bizarre they need ESLint plugins to remind people how they work.

klysm• 3 years ago

I don’t see why productive frameworks must be obvious. Once you learn how to think in functional react, it’s a very productive framework that enables you to bang out applications

ttfkam2• 3 years ago

There is nothing in React I'd regard as "terse". Perhaps slightly more terse than the mountain of boilerplate it required previously, but that's as far as I'd go.

https://youtu.be/AdNJ3fydeao?t=702

We really should accept that all of the following are ABSTRACTION LEAKS and not inherent benefits to web development at large:

  • shouldComponentUpdate
  • React.PureComponent
  • useMemo
  • useCallback
  • Concurrent mode

They exist solely because React's underlying model is insufficient and we, the developers, are being made to do the computer's job with all this optimization boilerplate. The VDOM is dying. Let it die. It's long past time to move on. Any further React development in the existing foundation is just continuing to build upon sand.

karaokeyoga2• 3 years ago

In many cases, we can use useMemo instead of useEffect:

- the function is run immediately (during the render cycle, not after)

- we can take advantage of the dependency array

I think the reason this pattern isn't more popular is that we're taught to use useMemo to memoize a result, but we can also use it more simply … to run a function (during the render cycle) whenever the dependency array changes.

Just call useMemo and don't assign the result to anything, such as:

useMemo(myFunction, [dependency array])

lukax• 3 years ago

useMemo is really nice for sync effects but it breaks hot reload because hot reload does not call useMemo again. E.g. you can subscribe to something using useMemo (so that it is synchronous and you can use the current subscription value in the current render) and then unsubscribe using useEffect as a cleanup callback. When the component is hot reloaded, the useEffect cleanup callback will be called but the useMemo will not be called again if the dependencies do not change. You can use useSyncExternalStore for that but you need to make sure that your subscription value is immutable or hack around it with refs.

Rapzid8• 3 years ago

This is underdiscussed IMHO. I refer to the render function calls as "the way down" and then after everything is mounted when React starts calling the useEffect callbacks "the way up".

Many applications suffer from the waterfall rendering problem but even for those that don't, if they are large, they will absolutely want to kick off network calls on "the way down". You can easily add a ton of time to LCP by waiting to kick network calls off until the tree has mounted.

I actually go a little out of my way to make sure as much of the tree as possible can render and mount with missing data. This way the work is occurring while data is fetching in parallel, and then a minimized number of components need to be updated once the data has arrived.

mrctte• 3 years ago

Isn't this exactly what useLayoutEffect is for? https://react.dev/reference/react/useLayoutEffect

karaokeyoga2• 3 years ago

useLayoutEffect is called after the render cycle but before the “paint”. useMemo is called during the render cycle (i.e. immediately).

You can confirm this via console.log:

useMemo(() => console.log(1), [])

console.log(2)

… will print 1 then 2.

If you replace useMemo with useLayoutEffect, you’ll get 2 then 1.

koromak2• 3 years ago

This is smart. I guess because the common wisdom you see repeated everywhere is "Never memoize unless you're sure of the benefits". Never thought about using them for any other purpose.

weird-eye-issue2• 3 years ago

Why is all of the text on this page bold?

rawoke0836005• 3 years ago

useBoldEffect() ?

weird-eye-issue2• 3 years ago

That's deprecated.

It is now useStrongEffect()

ricardobayes3• 3 years ago

Heavy fonts are the new "grey font on grey background".

the_gipsy13• 3 years ago

They let you “step outside” of React and synchronize your components with some external system like a non-React widget, network, or the browser DOM.

This doc is generally on point and a very important lesson to drill into the heads of people new to react, however that particular phrase is completely misleading. React is absolutely pushing you to use lifecycle effects where necessary. Calling that "stepping outside" is just dishonest.

React is not a "pure view library" that you have to integrate with state management. It makes you handle the extremely impure chain of (route change, component "mounting", data fetching...), all in the rendering code.

branko_d• 3 years ago

route change, component "mounting", data fetching...

This should really be:

route change -> data fetching -> rendering

After the data is fetched, it should just be assigned to a state somewhere, and the React should, well, "react" to the state change. This may seem a bit complicated for simple cases, but keeps the execution flow explicit and "steppable" though the debugger.

We use MobX for the "react" part; I'm sure this is not the only way.

the_gipsy13• 3 years ago

Yes, but that is The Elm Architecture. React's docs guide you towards using react-query and react-router, making everything lifecycle bound and the renders impure.

https://react.dev/reference/react/useEffect#what-are-good-al...

ojkelly2• 3 years ago

Calling that "stepping outside" is just dishonest.

I don’t think it’s dishonest. There’s two main phases in react, render and commit.

Render is interruptible. For example when a new event like an interaction comes in, the in progress render might get chucked out and restarted with the new information.

Commit isn’t interruptible. It’s a sync phase. This is where all the effects run, and the purpose is to take the new state from the render phase and synchronise it to the external systems. Aka cause side effects.

The useEffect hook running in the commit phase, does let you step outside of the react framework. It lets you safely interact with external systems. If you tried to do any of that in the render phase, you risk getting cut off halfway, or doing things out of order.

React is not a "pure view library" that you have to integrate with state management.

A view library without state management would be a templating engine right?

It makes you handle the extremely impure chain of (route change, component "mounting", data fetching...), all in the rendering code.

It lets you define how to respond to those changes in the render phase, but they aren’t applied until the commit phase.

And that means you can wrap up the complexity in well tested components that provide a simple API.

larsnystrom3• 3 years ago

useEffect is absolutely core to doing to react development with hooks. Saying "you might not need an effect" is like saying "you might not need the + operator", like yeah, sure, if you're not trying to add two numbers or concatenate a string or whatever you won't need that operator, but in like 99.999% of all applications you will need it.

muspimerol• 3 years ago

That's really not the point of the article. It's addressing overuse of useEffect(), not implying that you never need it.

larsnystrom3• 3 years ago

I think my gripe here is the casual use of “you might not need…”. It’s inspired by the “you might not need redux” article by Dan Abramov, but the difference here is that while you might not need Redux, you most likely will need useEffect. They’re just not same in that regard.

Maybe I’m just being pedantic here, but I think how you use words matters, and in this instance a better title would be “avoid unnecessary useEffect calls” or something like that. “You might not need an effect” is just poor (sloppy?) wording, because it’s usually objectively wrong.

The reason it matters in this instance is that with the current title I’m going into the article thinking I’ll learn some new way to do effects which is better than useEffect. But the article offers no alternative to useEffect. You will need useEffect.

Gunax2• 3 years ago

I think I disagree, or at least we might disagree on what operations are common in React.

When I have seen useEffect used, it's most often uneccesary. People are using it to create dependent state (ie. when x changes, then recalculate y) or to handle the result of an event.

It's really only needed in components that handle fetch responses, which IME is much fewer than 99.9%.

larsnystrom3• 3 years ago

Not 99.9% of components, but 99.9% of applications. Of course I haven’t actually done the numbers, but if your application fetches data or listens to browser events you will need useEffect. I’d estimate 99.9% of web apps using React do at least one of those things.

quickthrower22• 3 years ago

There you go. I thought `key` was something you just needed when creating child elements, so react knows which ones are which. I didn't realize it could be used to create a new sandbox for state. But actually it makes sense! Because if you have a list of child items each with it's own state then React needs to manage that using the key. I never made this connection.

dgb233• 3 years ago

It’s useful to think about key as the telling React of the identity of a component.

Whenever you want a stateful component that can be identified by a unique name, you’ll likely want to tell that to React via key.

sickcodebruh4• 3 years ago

My concern with using `key` for this is that it’s somewhat of a booby trap for future consumers of the component. It requires some kind of documentation that you need to hope they’ll read. TypeScript won’t help you. It’s not common enough that they’ll think to go looking for it. It’ll break silently and they won’t know until there’s a problem. Is the best practice to wrap a keyed-to-reset-state component in an unkeyed component and then exporting that? Seems like an odd pattern.

aeroaero3• 3 years ago

Not necessarily, the component itself can work without a key. Adding a key is just one approach to resetting component state from a parent. If a component can’t work properly without a key it should be wrapped further to make it usable rather than documenting it for all consumers.

quickthrower22• 3 years ago

I think I agree. I commented a while back I prefer components that don’t reset state based on props anyway.

Use state as little as possible and keep things pure and you probably won’t need this.

Example: date picker only keeps the open/close ui state of the picker. The date is a prop and date change is an event.

Instead of original date being a prop. Current date being local state.

rawoke0836005• 3 years ago

I like these types of articles, I come here and do Ctrl+F "svelte" I'm looking to see who is brave enough :)

ihateolives3• 3 years ago

For my personal projects it's always Svelte now. Fits how my brain works. I used to love React, but I must be getting old now and wish to have as little complexity in my life as possible.

eckza2• 3 years ago

Sometimes I Cmd+F "elm", but only on days where I feel like picking a fight.

ducks

giovannibonetti• 3 years ago

Yeah, Elm solves all of those problems through its purity-enforcing compiler. It's a shame so few people know about it.

yosito• 3 years ago

Using a key to reset state when props change is a great tip. I was using an effect to do that.

preommr• 3 years ago

This is something that I really dislike about the react ecosystem. The devs and community leaders keep being impractically obtuse about how the framework should be used and is used.

React isn't low level enough to be this unopinionated.

nasir• 3 years ago

A few months ago I need to build a small web app and decided to have a look at React. Pre Hooks, I had used React a lot so I thought it will be straightforward. Then I stumbled upon all these new paradigms wrapped in hooks to make an API call. Confused, I gave up and switched to classic Flask with template engines.

Seeing this reminds of the time I was spending to understand these concept and use them. Quite funny that the whole React ecosystem is turning into a classic server rendered mechanism with core functionalities being deprecated. I'm glad I stayed away.

wetpaws2• 3 years ago

Just don't use hooks. Why people think they are obliged to do the switch eludes me, feels like some kind of cargo cult.

continuational• 3 years ago

It's pretty clear that the class based API is a legacy thing in React by now. You can still use it, but the framework has moved on.

liendolucas2• 3 years ago

Same here. Flask with HTMX and bit of HyperScript (if you dare) has become very pleasant so far. I wished I had discovered it before. I do not know for sure if it can fulfill complex apps, but this also invites to rethink an app in terms of the original web instead, exchange HTML, not JSON + all the transformations that need to take place in the FE. I found the HTMX memes hilarious and very true actually: https://htmx.org/essays/ Maybe is time to rediscover simpler tools and frameworks.

Gunax2• 3 years ago

This is a footgun I found at a few Amazon internal apps recently. I was able to clear away probably 3/4 uses of useEffect--some of which I was guilty of adding.

Given how common this error is, there is definitely an unmet need. What people want is a listener, ie.: - recalculate a var whenever a prop changes (this is what useMemo is for) - trigger a function when a state changes (should be moved to the function that changed the state)

gardenhedge3• 3 years ago

That is not what useMemo is for. It's for caching a result and only recalculating it if the dependencies have changed. The aim is to optimize performance. It is not intended for listening to prop changes.

liendolucas2• 3 years ago

For the less hyped and esoteric audience of the framework that does not want to go with hooks and remain with a simple dumb model I wish they don't deprecate the class based model but that seems to be already happening: https://react.dev/reference/react/legacy. In few years in the future who knows with what new thing they will come up with. Meh.

TheCoelacanth2• 3 years ago

Every single one of these examples has a nearly identical anti-pattern using componentDidMount or componentDidUpdate.

There's nothing here that's specific to hooks. It's just people misunderstanding the React lifecycle.

batmansmk• 3 years ago

I lead a 4 dev team working with a React codebase of 80k LoC for 2 years. Hooks' lack of orchestration mechanism, props drilling and its quirks, wrong dependency arrays, setTimeout not cleaned up, and other misuses of the framework were the cause of 7 of the 28 bugs we fixed in prod in March 2023 so far. Every other PR there is a debate around a hook lifecycle gotcha. Is it a lot? I think it is.

rickstanley• 3 years ago

  //  Good: This logic should run because the component was displayed
  useEffect(() => {
    post('/analytics/event', { eventName: 'visit_form' });
  }, []);

And then a wild 'exhaustive-deps'[0] appears!

[0] https://github.com/facebook/react/issues/14920

andrewingram6• 3 years ago

There aren't any function-scope variables used here, so an empty dependency array is correct.

brap• 3 years ago

I think we've reached the point where React is ready to be challenged by a new competitor. Unfortunately I haven't seen one yet.

wizofaus• 3 years ago

LLMs may well obviate the need for further JS frameworks - at least ChatGPT seems to be just a capable of generating pure JS vs framework-based JS from what I've seen so far. At any rate the sorts of things it's good (and not good) at doing don't seem to vary with the choice of framework. Having said that, as long as there's an expectation the generated code still needs maintenance by human devs, there may be a reluctance to step back from frameworks.

Sammi6• 3 years ago

There are currently two new web frontend frameworks that are sharply on the rise: Svelte and Solid.

Both do away with much of the complexity of React.

yakshaving_jgt3• 3 years ago

If you'd consider an old competitor, then Elm does everything better and is much easier to learn.

Sammi6• 3 years ago

Too closed off to the world. You can't win over the world if you are closed off to it.

Elm has been going nowhere for ages now, and will continue to go nowhere, as long as they keep not listening and don't give people what people ask for.

sickcodebruh4• 3 years ago

My experience has taught me that when developers consistently use your tools “wrong”, it’s a sign that the tools themselves are the problem. The use cases described in this document outline common needs that shouldn’t be so easy to get wrong. It reads like a call to action for an expansion and rethinking React’s public interface via new hooks or utility functions. You can’t always document the pain away. I’m not a React maintainer so I don’t know how easy or possible this is, but considering all the fantastic things the team has done, there’s no way that this is their best.

To paraphrase an old quote, “If you see bad code with your utility all day, perhaps your utility is the bad code.”

ep1032• 3 years ago

Joel on Software - The Pit of Success applies here, yet again

mcgwiz• 3 years ago

<aside>

Joel is a great but credit for this goes to Rico Mariani, originally quoted here https://web.archive.org/web/20100514093413/http://blogs.msdn...

</aside>

gardenhedge3• 3 years ago

disagree completely. the problem is newbie devs are learning react without know javascript first

tadfisher• 3 years ago

I submit that React would have appropriately zero users if it nailed down its API to only allow the "right" way of using it from day 1.

frodowtf• 3 years ago

React would have needed its own domain-specific language to get around the implicit reference insanity and other quirks of JS.

Capricorn24813• 3 years ago

This is in line with how I was taught how to use React years ago. I'm surprised so many people are angry with these new docs. React has been such a productivity boon for us and every time I have to work in Angular, I'm reminded of how unnecessarily complicated it is for a frontend framework.

Many useEffects can be replaced with event handlers and calculated constant variables

ep1032• 3 years ago

React is still easier to work with than angular, depending on your application, even with these issues. But these are still issues : )

Capricorn24813• 3 years ago

What issues? This is an update to the docs to reinforce best practices that have been around for a while now. People are acting like there's been sudden breaking API changes. useEffect has always been a last resort technique, and even the old docs reinforced this. People saying things like "They recommended Next.js for starter projects, so they're giving up on SPAs?" both don't understand what Next.js is and, really, just want to be angry about something.

The response to this has been absurd. Dan Abramov has been active in the community and transparent about the documentation, and he has gotten direct ad hominem attacks from the same community.

It's just the same story: People that feel lost using React claiming the rest of tech world is fed up with it, and it will be dead next year. I question whether they even do frontend work that much, or are really backend devs forced to do it once in a blue moon. Meanwhile every other library/framework trying to "outdo" react just falls short in so many areas. I welcome the competition, but it's clear that these aren't the members of the community that should be tastemakers for frontend design.

willio58• 3 years ago

A year ago I was applying for jobs (react jobs mostly) and got a take home project with angular. I shrugged and said why not? I stared at the angular docs for about 2 hours and emailed the recruiter saying “no thanks”. Angular is such a departure from anything I’ve used before. Meanwhile react is just simply component based and if you need things like global state you can add zustand and it all just makes sense. Angular felt like a ton of boilerplate (kinda like class-based react but so much more) and I just couldn’t imagine writing code in it daily.

Later on I got a job in react with typescript and serverless functions and it’s a dream.

satvikpendem• 3 years ago

We need articles like these because people don't understand that React is fundamentally an idempotent framework. The function component or render method, well, renders every single time props or state change. Hooks are just a way to have some higher order state and if you think of React as UI = f(state), then the state variable also captures hook state as its input. It would be more clear to say UI = f(state, useState variable 1, useState variable 2, useEffect function 1, ...).

whalesalad• 3 years ago

Anyone here jump ship to Vue3 w/ it's composition API? I feel like Vue has the best of both worlds by offering a functional paradigm (composition api) while still supporting the classical object-based options API. I am slowly transitioning object/options components over to the composition approach in a continuous improvement approach. The ability to do that at my own leisure has been quite nice.

I'm inclined to think Vue is the better framework, but React has a larger ecosystem.

(Not intending to start a flame war here)

FallDownTS• 3 years ago

The reactivity system in react is certainly "outdated" when compared to Vue, Svelte, Solid, or pretty much any newer framework. But it's just as you said, the larger ecosystem does have its benefits. There are a few libraries like Framer motion, that don't have equivalent support in other frameworks.

ojkelly2• 3 years ago

It’s all cyclical.

Before React two-way-binding of data, known today as Signals, was the way we did things. Angular is probably the best example from the pre-react time of that.

React came along with a philosophy of one-way-binding also known as unidirectional data flow. I’ve stuck with it because I think it enables much better local reasoning, and more predictable outcomes.

Neither are outdated.

I’d wager the most performance critical use cases would benefit from signals, things like tldraw.

But unless you’re doing something which needs to paint every single frame (ignoring animation/transitions), the extra overhead and mental load required by Signals is excessive. It’s overly complex and harder to reason about.

With no disrespect to Vue, Svelte, Solid, etc, they feel outdated in the way Angular does.

evnp• 3 years ago

Yes, we're using Vue 3 and composition-style components over at https://radiopaper.com. My only gripe is that Vue's standard templates can't be typed as thoroughly as JSX can (IME - after mixed experiences with Vetur/VTI[1]), but we've been gradually migrating everything to TSX via render functions[2] and finding it perfectly capable. Added bonus is an ease of composition of template code – small local-use components can easily be split out within the same file for readability, in contrast with Vue SFC's. Vue even has true "function components" now! [3] (nice to have in really minimal cases)

[1] https://vuejs.github.io/vetur/guide/vti.html [2] https://vuejs.org/guide/extras/render-function.html [3] https://vuejs.org/guide/extras/render-function.html#function...

The5thElephant• 3 years ago

I love Vue 3, but 99% of the reason I love it is the SFCs and not using JSX/TSX most of the time. Vue can't optimize render functions as well as it can optimize templates, and templates are significantly more approachable for people like me who come from the design/HTML/CSS world and want to contribute to the codebase (especially since most front-end devs coming from JS world suck at HMTL/CSS).

Is typing really the main issue there? Working in render functions and TSX is sooooo much more clunky for doing the same basic things, and you lose all the nice benefits of Vue's SFCs and things like built-in class array logic.

CSSer• 3 years ago

I'm still confused. They present an example where they load data from local storage but do not make it clear how that data is passed out to the app.

What if I'd like to always initialize my app's state with the data in local storage? Let's say I want to initialize from localStorage and pass this to context. Doing so triggers a hydration error in React v18 because the server-side value will never match the hydrated value once set. It seems like a job for useSyncExternalStore since that's what localStorage is (an external key-value store), but the ergonomics of the subscribe function seem odd to me.

robopsychology• 3 years ago

People talk about the benefits of a functional architecture with UIs and how I guess you can see it as a data stream where FP helps think about things, but surely Smalltalk-style OO with messages would be the best way to represent something that both requires a lot of back-and-forth but also widget state? Are there any OO-style web frameworks that are popular nowadays?

imbnwa• 3 years ago

Does Apple's preference for the Delegate pattern touch on this?

sroussey• 3 years ago

It says not to use effects, but then suggests useMemo which is an effect!

jsmith45• 3 years ago

I'm not sure that useMemo really is an effect in the sense that useEffect is. The useMemo callback is invoked synchronously during render, rather than getting pushed onto an effect queue like useEffect does.

Even useLayoutEffect goes on an effect queue, and if it results in changes, will need to render a second time, while a changed memo calculation happens entirely during the single render pass.

greenie_beans• 3 years ago

this is great. i learned some instances where i've been improperly using effects.

there are a ton of tutorials out there that teach new react devs the wrong patterns. really low bar of entry to put some article up on medium or dev.to about "useEffect tutorial". and then those devs go on to write their own tutorials that are misguided, etc

tr0waway• 3 years ago

You might not need react.

gloryjulio• 3 years ago

It's really tiring to keep seeing the bashing on the effect on hn. It's an advanced tool to replace hoc hell where you need reusable shared logic. In the doc it's even stated as such and also stated that it's for cross cutting logic. If you haven't seen hoc hell before when using classes, that only means your usecase was not complex enough for this kind of tools

gardenhedge3• 3 years ago

awesome! I've always wondered why people relied on useEffect so much. I've been using it perfectly

koromak2• 3 years ago

I despise the prevValues paradigm that crops up. Its even recommended in these docs, under "Adjusting some state when a prop changes"

Having to keep a second variable around for every prop you need to compare is just miserable to work with. useEffect is less efficient, but so much more obvious in a situation like this. "I want to do something when this value changes, and ONLY when this value changes" seems like something React should be able to handle elegantly. It happens literally all the time.

andrewstuart• 3 years ago

React has jumped the server side shark.

You might not need an effect

Related Stories