DEV Community

Cover image for When useEffect runs

When useEffect runs

Cassidy Williams on February 10, 2023

useEffect is one of those React/Preact hooks that most people have a love/hate relationship with, but like it or not, it's good to understand how i...
Read full post
Collapse
 
thethirdrace profile image
Info Comment hidden by post author - thread only accessible via permalink
TheThirdRace • • Edited

The title is very misleading as the article doesn't explain when useEffect is called...

Not to mention there are couple points I'm pretty sure are wrong in the article...

When useEffect is called?

The real moment when useEffect is called is after every render.

==> AFTER not during <===

Effects let you run some code after rendering so that you can synchronize your component with some system outside of React.
-- beta.reactjs.org/learn/synchronizi...

But for a better understanding of how things fits together, here's a rundown of how it actually works...

Phase 1: React Render

React renders the component in memory, meaning it executes the function or class component to know what it will produce in output.

Phase 2: React Comparison

There's a comparison phase between React's output, also known as Virtual DOM or VDOM, and the real DOM from the browser.

Phase 3: React Reconciliation/Commit or React Render Opt-out

If the output is the same as the DOM, React will discard the render and won't proceed further with the current change, meaning it will skip the remaining phases. See bailing out of a state update

If the output differs from the DOM, React will pass the necessary instruction to the browser to adjust its DOM. ex: add/remove DOM nodes, modify text, etc. It's during this time that useEffect's callback is scheduled.

Phase 4: React useEffect is run and its callback is scheduled

React will run each useEffect in the order they were registered and schedule their callbacks.

===> This is the WHEN useEffect is run, but not when it's callback is run <===

It's a very important nuance you need to understand, useEffect runs pretty early, but its callback is a deferred event that runs after the browser's render and paint for performance reasons. It's all about the renders.

It's also important to understand that you can change the values in the dependency array however you want, but as long as there's no re-render, the callback given to useEffect will NEVER execute.

Causality can be expressed like this:

  1. State changed
  2. Render
  3. useEffect is fired if React didn't bail out of the render
  4. callback passed to useEffect will be scheduled to run later only if at least 1 value of the dependency array has changed (think of the deferred execution as a requestIdleCallback)

Phase 5: Browser Render

The browser will modify its DOM. This operation happens in memory and everything like CSS will be recalculated during this browser "render" phase

Phase 6: useLayoutEffect

React will run synchronously the useLayoutEffect after the browser's DOM was modified so you can now check nodes size or position or anything that needs the DOM for processing.

===> This hook runs synchronously after the browser render <===

Don't use useLayoutEffect unless you absolutely need it as it will block the JS main thread, which would degrade your app performance.

Phase 7: Browser Painting

The browser will repaint the screen and the user will see the changes.

Phase 8: React useEffect's callback

Once the main thread is "idling", the callbacks will be run in the order they were registered.

Again, this is NOT when useEffect is run, it ran much earlier, it's just the callback that was scheduled that runs at this time.

The callbacks run so late in the cycle because of 2 reasons:

  1. they're supposed to be synchronizing with external systems, meaning they're not important for actual rendering and they can happen later
  2. deferring execution later improves render performance greatly

Notes

All the phases are asynchronous, but are called in a specific order.

Since useEffect's ===> callback <=== is deferred, it's supposed to run last but it's not a guarantee. While it can't happen before running useEffect (phase 4), it could happen as early as before the browser render (phase 5) depending on how the browser optimizes its work. This is why the useLayoutEffect hook was created, to give us a handle when we need to make sure DOM modifications are applied first (although it has performance implications).

Things I believe the article got wrong

So, it does get a little hairy because useEffects behavior has changed a bit across framework updates, but at a high level: it's called on component mount, and whenever anything in the dependency array changes

I'm not aware of any change on when or how the useEffect has been called since its inception. I think it's more of a misconception than anything else. useEffect has always been the same, we just didn't quite catch how it worked...

Also, useEffect is not called on mount, it's called because there was a render which happens to be the first render, aka on mount. It's a small nuance, but it's important to get the difference to better understand the model. It's not the mounting, it's the render that called it.

And every subsequent calls are also because there was a render, not because the dependency array values changed. Granted, you'd need to use pretty weird patterns to not re-render and change a value, but it's possible. Try using a ref in the dependency array and change it, the useEffect will NEVER run after that change because ref will never cause a re-render. Again, it's a small nuance, but it's important to get the difference to better understand the model. It's not the change to the dependency array, it's the render that causes the call to useEffect.

Or to rephrase, React/Preact calls the clean-up functions when a component unmounts, or when an update is made and it needs to "cancel" the previous effect.

Same as with the previous statements. It has nothing to do with mounting, unmounting or updating values, it's all about renders:

There's a render => run clean up function => run `useEffect`
Enter fullscreen mode Exit fullscreen mode

It's all top => down, pretty simple stuff when you think about it.

And 1 more important thing to understand...

===> useEffect will ALWAYS be called after a render, the dependency array is only there to decide if the callback passed to useEffect should be executed or not<===

In other words: useEffect will execute after a render no matter what, the callback passed to useEffect will only execute if values in the dependency array changes.

Because of how the new Suspense functionality works and a bunch of other changes that happened in React 18, useEffect needs to be manipulated more to run just once in development and strict mode

Not really, useEffect is to synchronize stuff. It shouldn't matter that your synchronization runs twice on the first render.

If there's a problem, then your effect has a problem in design. It's also possible you shouldn't use useEffect for that particular thing either...

I highly recommend to read React's official beta documentation, especially the page You might not need an effect

Collapse
 
vanyaxk profile image
Ivan •

Great article! Why do useEffects trigger when they use callbacks sent as props from the parent? It does not happen with simple callbacks, like the ones from useState though

Collapse
 
tejasq profile image
Tejas Kumar •

It’s because the useEffect does a shallow comparison of the values in its dependency array.

Consider the following scenario:

(() => true) === (() => true)
Enter fullscreen mode Exit fullscreen mode

We’re comparing a function that returns true with another function that returns true. We think they’re the same, but to React, they’re two different functions because they’re both initialized as two distinct functions even though they do the same thing.

If we compare references to functions, then we have equality:

const a = () => true;
const b = () => true;
const c = a;

a === a; // true
a === b; // false
a === c; // true
Enter fullscreen mode Exit fullscreen mode

Comparing references, not values achieves the effect you want.

The callbacks from useState are references.

Another way you can go about this is by wrapping your callbacks in useCallback for even more control.

Collapse
 
vanyaxk profile image
Ivan •

Thanks a ton, this explains it!

Thread Thread
 
tejasq profile image
Tejas Kumar •

Happy to serve you, Ivan!

Collapse
 
codeofrelevancy profile image
Code of Relevancy •

Great article. Thank you for sharing.
The useEffect hook is truly a game-changer, it elegantly combines simplicity and functionality, making it an essential tool for any React developer..

Collapse
 
gene profile image
Gene •

Thank you!

Collapse
 
bookercodes profile image
Alex Booker •

Brilliant explanation @cassidoo. I love the way you write!

Collapse
 
rishadomar profile image
Rishad Omar •

Thanks for this articles and the comments below help my understanding.

Collapse
 
lindiwe09 profile image
Lindiwe Dokotala •

l value the insights and guidance you provide @cassidoo . l love the way you write.

Collapse
 
shiraze profile image
shiraze •

Hi, I'm pretty sure the example with let isCurrent = true is incorrect, as isCurrent will be set to true each time the useEffect is fired (after initial render, and whenever uid updates), so will mean that setUser() will be called at each of these times. You could make use of useRef() to make sure it's only called initially, or use the empty dependency array.

Collapse
 
cassidoo profile image
Cassidy Williams •

It depends on the fetch timing! If fetch is particularly slow and the uid changes, then the isCurrent will be false for that original fetch call. The functions in useEffect are called in a stack of sorts, with a new isCurrent variable for each one.

Collapse
 
shiraze profile image
shiraze •

I thought the fetch promise behaves similar to an enclosure (i.e. the value of inner vars are based on the value of outer vars at the time the function/promise is defined), so I created this codepen to check behaviour: codepen.io/ambience/pen/PodYBqa

You are correct @cassidoo, and we can see from the codepen that if multiple clicks on the button to update uid is made in quick succession, only the last click results in the setUser call being made.

Collapse
 
rei7 profile image
rei •

everyone, before you use "ref flag" to bypass react 18+ strict mode running twice, you should know it's actually designed to be a beneficial FEATURE to help catch bugs and find problems. React docs goes to great length talking about it.

Some comments have been hidden by the post's author - find out more