You might not need an effect

IMO if you need a long doc like this pointing out the sharp edges, then I think you&#x27;ve done a poor job in designing the framework.<p>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.<p>I&#x27;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&#x27;ll check out Solid next time, which seems to have less weird edge cases.

&gt; Effects are an escape hatch from the React paradigm<p>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&#x27;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!<p>I&#x27;m really just put off by the React documentation in general. It feels like it&#x27;s aimed at junior devs working on FE assembly lines and they want to keep the blinders on them. &quot;Pay no attention to the man behind the curtain!&quot;.

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.<p>To paraphrase an old quote, “If you see bad code with your utility all day, perhaps your utility is the bad code.”

Interesting Detail about this from Dan Abramov:<p><a href="https:&#x2F;&#x2F;twitter.com&#x2F;dan_abramov&#x2F;status&#x2F;1638773531881140224" rel="nofollow">https:&#x2F;&#x2F;twitter.com&#x2F;dan_abramov&#x2F;status&#x2F;1638773531881140224</a><p>&gt; 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.<p>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.

I lead a 4 dev team working with a React codebase of 80k LoC for 2 years. Hooks&#x27; 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.

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.<p>React isn&#x27;t low level enough to be this unopinionated.

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.<p>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.

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.<p>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&#x27;m glad I stayed away.

Anyone here jump ship to Vue3 w&#x2F; it&#x27;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&#x2F;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.<p>I&#x27;m inclined to think Vue is the better framework, but React has a larger ecosystem.<p>(Not intending to start a flame war here)

This is in line with how I was taught how to use React years ago. I&#x27;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&#x27;m reminded of how unnecessarily complicated it is for a frontend framework.<p>Many useEffects can be replaced with event handlers and calculated constant variables

Weirdly disappointed, turns out I still need useEffect because I&#x27;ve been using it as intended.

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&#x27;t deprecate the class based model but that seems to be already happening: <a href="https:&#x2F;&#x2F;react.dev&#x2F;reference&#x2F;react&#x2F;legacy" rel="nofollow">https:&#x2F;&#x2F;react.dev&#x2F;reference&#x2F;react&#x2F;legacy</a>. In few years in the future who knows with what new thing they will come up with. Meh.

In many cases, we can use useMemo instead of useEffect:<p>- the function is run immediately (during the render cycle, not after)<p>- we can take advantage of the dependency array<p>I think the reason this pattern isn&#x27;t more popular is that we&#x27;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.<p>Just call useMemo and don&#x27;t assign the result to anything, such as:<p>useMemo(myFunction, [dependency array])

There you go. I thought `key` was something you just needed when creating child elements, so react knows which ones are which. I didn&#x27;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&#x27;s own state then React needs to manage that using the key. I never made this connection.

&gt; 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.<p>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 &quot;stepping outside&quot; is just dishonest.<p>React is not a &quot;pure view library&quot; that you have to integrate with state management. It makes you handle the extremely impure chain of (route change, component &quot;mounting&quot;, data fetching...), all in the rendering code.

I&#x27;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.<p>What if I&#x27;d like to always initialize my app&#x27;s state with the data in local storage? Let&#x27;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&#x27;s what localStorage is (an external key-value store), but the ergonomics of the subscribe function seem odd to me.

I despise the prevValues paradigm that crops up. Its even recommended in these docs, under &quot;Adjusting some state when a prop changes&quot;<p>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. &quot;I want to do something when this value changes, and ONLY when this value changes&quot; seems like something React should be able to handle elegantly. It happens literally all the time.

I like these types of articles, I come here and do Ctrl+F &quot;svelte&quot; I&#x27;m looking to see who is brave enough :)

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

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

This is a footgun I found at a few Amazon internal apps recently. I was able to clear away probably 3&#x2F;4 uses of useEffect--some of which <i>I</i> was guilty of adding.<p>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)

You might not need React

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

We need articles like these because people don&#x27;t understand that React is fundamentally an idempotent framework. The function component or render method, well, <i>renders</i> 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, ...).

<p><pre><code> &#x2F;&#x2F; Good: This logic should run because the component was displayed useEffect(() =&gt; { post(&#x27;&#x2F;analytics&#x2F;event&#x27;, { eventName: &#x27;visit_form&#x27; }); }, []); </code></pre> And then a wild &#x27;exhaustive-deps&#x27;[0] appears!<p>[0]: <a href="https:&#x2F;&#x2F;github.com&#x2F;facebook&#x2F;react&#x2F;issues&#x2F;14920">https:&#x2F;&#x2F;github.com&#x2F;facebook&#x2F;react&#x2F;issues&#x2F;14920</a>

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?

huh.<p>well I’m lost then.<p>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.<p>still looks like I need to relearn something.

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

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

this is great. i learned some instances where i&#x27;ve been improperly using effects.<p>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 &quot;useEffect tutorial&quot;. and then those devs go on to write their own tutorials that are misguided, etc

Why is all of the text on this page bold?

You might not need react.

React has jumped the server side shark.

awesome! I&#x27;ve always wondered why people relied on useEffect so much. I&#x27;ve been using it perfectly

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