You wrote some components in Hooks, or even a small application. You may be satisfied that you are comfortable with its API and have picked up a few tricks in the process. You might even have written a few Custom Hooks to remove repetitive logic (saving 300 lines of code) and proudly showed them to your colleagues, “Well done,” they said.

But sometimes when you use the useEffect you feel something is wrong. You mutter that you might be missing something. It looks like the life cycle of class… But is it really true? You find yourself asking questions like:

  • 🤔 how to useuseEffectsimulationcomponentDidMountLife cycle?
  • How to 🤔 correctlyuseEffectRequest data in?[]What is it?
  • 🤔 Should I treat a function as an effect dependency?
  • 🤔 Why do endless repeated requests sometimes occur?
  • 🤔 Why do I sometimes get old State or prop in Effect?

When I first started using Hooks, I was troubled by the same issues above. Even when I wrote the original document, I didn’t have a solid grasp of some of the details. I had some “aha!” moments that I wanted to share with you. This article will go into depth to help you understand the answers to these questions.

Before we look at the answer, we need to take a step back. The purpose of this article is not to give you a bullet point list, but to help you really understand the useEffect. We don’t really have much to learn. In fact, we spend a lot of time trying to unlearn certain concepts that we’ve already learned.

When I stop peeking through the familiar class lifecycle approachuseEffectThis Hook, I was able to understand.

“Forget what you’ve learned.” – Yoda

This article will assume that you are rightuseEffectSome level of understanding of APIS.

This article is really long. It’s more like a mini book, which is my preferred format. If you’re in a hurry or not too interested in the topic of this article, you can also read the summary below.

If you don’t feel comfortable with in-depth research, you might want to wait for the following explanations to appear in other articles. When React first came out in 2013, it took time to digest a different mental model. Knowledge also takes time to spread.

Abstract

If you don’t want to read the whole article, take a quick look at this summary. If a section is not easy to understand, you can scroll down to find relevant content to read.

If you’re going to read the whole article, you can skip this part altogether. I’ll include a link to the abstract at the end of the article.

🤔 Question: How to use ituseEffectsimulationcomponentDidMountLife cycle?

UseEffect (fn, []) can be used, but they are not exactly equal. Unlike componentDidMount, useEffect captures props and state. So even in the callback function, you still get the original props and state. If you want the “latest” value, you can use ref. However, there are usually simpler implementations, so you don’t have to use ref. Keep in mind that the mental model of Effects is different from componentDidMount and other life cycles, and trying to find exactly the same expression between them is more likely to confuse you. To be more effective, you need to “think in Effects,” whose mental model is closer to achieving state synchronization than to responding to life cycle events.

🤔 Question: How to correct inuseEffectRequest data in?[]What is it?

This article is a good introduction to how to make data requests in useEffect. Be sure to read it! It’s not as long as mine. [] indicates that effect does not use any values in the React stream, so it is safe to call effect only once. [] is also the source of a common problem where you think you are not using a value in the data stream but you are. You need to learn some strategies (mainly useReducer and useCallback) to remove these effect dependencies rather than mistakenly ignoring them.

🤔 Question: Should I treat a function as an effect dependency?

It is generally recommended that functions that do not depend on props and state be outside of your components, and functions that are only used by effect be inside effect. If, after doing so, you still need to use functions inside the component (including functions passed in through props), you can use a useCallback layer where you define them. Why do you do that? Because these functions have access to props and state, they participate in the data flow. The FAQ on our website has more detailed answers.

🤔 Question: Why do you sometimes have an infinite number of repeated requests?

This usually happens when you make a data request in Effect without setting an effect dependent parameter. Without setting dependencies, effect is executed once after each render, and then updates the state in effect to cause the render and trigger effect again. Infinite loops can also happen because the dependencies you set are always changing. You can figure out which dependencies are causing the problem by removing them one by one. However, removing the dependencies you use (or blindly using []) is often the wrong solution. What you should do is tackle the root cause of the problem. For example, functions can cause this problem. You can place them in effects, or outside components, or wrap them in useCallback. UseMemo can do something similar to avoid generating objects repeatedly.

🤔 Why do I sometimes get old State or prop in Effect?

Effect always gets props and state from the render that defined it. This can avoid some bugs, but can be annoying in some scenarios. For these scenarios, you can explicitly store some values using mutable refs (explained at the end of the article above). If you feel like you’re getting old props and states in a render that you didn’t want, you’re probably missing some dependencies. Try using the Lint rule to train you to find these dependencies. After a few days, it might seem like second nature. You can also see this answer in our FAQ.

I hope this summary is helpful! Or, let’s start the text.

Each render has its own Props and State

Before we talk about Effects, we need to talk about rendering.

Let’s look at a Counter component, notice the line highlighted:

What does highlighted code mean? Does count “listen” for changes in status and update automatically? This may be a useful first instinct for learning React, but it’s not an accurate mental model.

In the example above, count is just a number. It’s not some magical “data Binding,” “Watcher,” “proxy,” or anything else. It’s just a regular number like this:

When our component first renders, it gets the initial count value of 0 from useState(). When we call setCount(1), React will render the component again, this time with count 1. And so on:

React will re-render the component when we update the state. Each render gets its owncountState, the value of which is a constant in the function.

So this line of code doesn’t do any special data binding:

It simply inserts the number count into the render output. This number is provided by React. When setCount is set, React calls the component again with a different count value. React then updates the DOM to keep it consistent with the rendered output.

The key point here is that the count constant in any render does not change over time. The render output changes because our component is called from time to time, and the render resulting from each call contains a count value independent of the other renderings.

(A more in-depth discussion of this process can be found in another of my articlesReact as a UI Runtime).

Each render has its own event handler

So far so good. What about event handlers?

Look at the example below. It will alert count of clicks after three seconds:

If I follow these steps:

  • Click to increase counter to 3
  • Click on “Show Alert”
  • Click to increase counter to 5 and complete before the timer callback triggers

Guess what alert pops up? Could it be 5? – This value is the real-time status of counter when it is alert. Or could it be three? — This value is the state when I click.

Reveal plot warning

Try it out for yourself!

If the result is not what you expect, you can imagine a more practical example: a chat app that stores the ID of the current recipient in State, along with a send button. This article delves into why. The correct answer is 3.

Alert “captures” the state when I click the button.

(There are other ways to implement different behaviors, but for now I’ll focus on this default scenario. When building a mental model, it is important to identify the “path of least resistance” among alternative strategies.

But how exactly does it work?

We find that count is a constant value in every function call. It is worth emphasizing – our component function is called every time we render, but the count value is constant in each call, and it is given the state value in the current render.

This isn’t unique to React; ordinary functions behave similarly:

In this example, the outer someone will be assigned multiple times (just as in React, the current component state will change). Then, in the sayHi function, the local constant name is associated with person in a call. Because this constant is local, each call is independent of the other. As a result, each alert pops up its own name when the timer callback is triggered.

This explains how our event handler captures the count value at click time. If we apply the same substitution principle, each render “sees” its own count:

So each rendering actually has a “new version” of handleAlertClick. Each version of handleAlertClick “remembers” its own count:

That’s why in this demo, the event handler “belongs” to a particular render, and when you click, it uses the state of counter from that render.

During any render, the props and state are always the same. If props and state are independent of each other in different renderings, then any values used for them are also independent (including event handlers). They all “belong” to a particular render. Even the asynchronous function call in event processing “sees” the count value in this render.

Note: ABOVE I will be specificcountThe values are directly inlinedhandleAlertClickIn a function. This mental substitution is safe becausecountValues cannot be changed in a particular render. It’s declared as a constant and a number. It’s also safe to think about other types of values like objects, provided we all agree that we should avoid directly changing state. By calling thesetSomething(newObj)It is better to generate a new object rather than modify it directly, as this ensures that the state in the previous rendering is not contaminated.

Each render has its own Effects

This article is about effects, but we haven’t talked about effects yet! Anyway, from the above analysis, it turns out that effects are really no different.

Let’s go back to this example from the official documentation:

Here’s a question for you: How does Effect read up to datecountWhat about the state values?

Perhaps, is there some “data binding” or “watching” mechanism that allows count to be updated within the effect function? Or maybe count is a mutable value and React changes it inside our component so that our effect function always gets the latest value?

Neither.

We already know that count is a constant in a particular render. The event handler “sees” the value of the count state that belongs to its particular render. The same is true for Effects:

Is notcountThe value of is changed in “constant” effect, butThe effect function itselfIt’s different in every render.

Each effect version “sees” a count value from the render it belongs to:

React remembers the effect function you provided and will call it every time the change is applied to the DOM and the browser draws the screen.

So while we’re talking about an effect, each render is a different function — and each effect function “sees” props and state from the particular render to which it belongs.

Conceptually, you can imagine effects being part of the result of the render.

Strictly speaking, they are not (in order to allow Hook composition without introducing awkward syntax or runtime). But in the mental model we built, the effect function belongs to a particular render, just like the event handler.

To make sure we have a solid understanding, let’s review the first rendering process:

  • React:Give me the status0Time UI.

  • Your component:

    • Give you the content you need to render:<p>You clicked 0 times</p>.
    • Remember to call this effect after rendering:() => { document.title = 'You clicked 0 times' }.
  • React: No problem. Start updating the UI, feed the browser, and I’m going to add something to the DOM.
  • Browser: Cool, I’ve drawn it on the screen.

  • React: Ok, I’ll now run the effect given to me

    • run() => { document.title = 'You clicked 0 times' }.

Now let’s review what happens after we click:

  • Your component:Hey React, set my state to1.
  • React:Give me the status1Time UI.

  • Your component:

    • Give you the content you need to render:<p>You clicked 1 times</p>.
    • Remember to call this effect after rendering:() => { document.title = 'You clicked 1 times' }.
  • React: No problem. I started updating the UI, feeding the browser, and I modified the DOM.
  • Browser: Cool, I’ve already drawn the changes to the screen.

  • React: Ok, I’ll now run effects for this render

    • run() => { document.title = 'You clicked 1 times' }.

Every render has its own… all

We now know that Effects will run after each render, and that it is conceptually part of the component output and can “see” the props and states that belong to a particular render.

As a thought experiment, consider the following code:

What happens if I click multiple times and set the delay in Effect?

Reveal plot warning

You might think this is a tricky problem and the result is counterintuitive. Totally wrong! What we see is a sequential printout – each one belongs to a particular render and therefore has the count value it should have. Try it for yourself:

You might think, “Of course it should. What else would it have been?”

However, this.state in class doesn’t work that way. You might assume that the following class implementation is equivalent to the above:

However, this.state.count always points to the latest count value, not the value that belongs to a particular render. So you’ll see that each printout is 5:

I find it ironic that Hooks rely so heavily on Javascript closures. Sometimes the component’s class implementation suffers from the canonical wrong-value-in-a-timeout confusion, But the real source of confusion in this example is mutable data (React modifies this.state in the class to point to the latest state), not the closure itself.

Closures are great when the closed value never changes. And that makes them very easy to think about because you’re essentially referencing constants. As we discussed, props and state do not change in a particular render. By the way, we can fix the above class version using closures…

tide

By now, we can explicitly shout out the important fact that functions within each component (including event handlers, effects, timers, or API calls, etc.) capture props and state defined in a particular render.

So the following two examples are equivalent:

It doesn’t matter when the props or state is read in the component. Because they don’t change. Throughout the scope of a single render, the props and state remain the same. (Deconstructing the props for assignment makes this more obvious.)

Of course, sometimes you might want to read the latest value in the effect callback instead of the captured value. The easiest way to do this is to use Refs, which is covered in the last section of this article.

Note that when you want to read future props and state from functions rendered in the past, you are swimming against the tide. While there is nothing wrong with it (and it may sometimes be necessary to do so), it makes the code look less “clean” by breaking the default paradigm. This is intentional because it helps highlight which code is vulnerable and time-dependent. In class, it’s not so obvious if this happens.

The following counter version emulates the behavior in class:

Changing values directly in React looks a little weird. However, React does exactly that in the class component. Unlike captured props and state, you can’t guarantee that latestCount.current read in any callback function is constant. By definition, you can change it at any time. That’s why it’s not the default behavior, but something you actively choose to do.

What about cleaning in Effect?

As explained in the documentation, some Effects may require a cleanup step. Essentially, it aims to eliminate side effects, such as unsubscribing.

Consider the following code:

Suppose the props were {id: 10} for the first rendering and {id: 20} for the second rendering. Here’s what you might think happened:

  • The React to clear the{id: 10}The effect of.
  • The React to render{id: 20}UI.
  • Run the React{id: 20}The effect of.

(That’s not the case.)

If you rely on this mental model, you might think that the purge process “sees” the old props because it was running before the re-rendering, and that the new effect “sees” the new props because it was running after the re-rendering. This mental model is derived directly from the life cycle of a class component. But it’s not exact. Let’s find out.

React will only run Effects after the browser has drawn. This makes your application much smoother because most effects don’t block updates on the screen. Effect clearing is also delayed. The previous effect will be cleared after rerendering:

  • The React to render{id: 20}UI.
  • Browser drawing. We see it on the screen{id: 20}UI.
  • The React to clear{id: 10}The effect of.
  • Run the React{id: 20}The effect of.

You might be wondering: if clearing the previous effect happened after props became {id: 20}, why is it still “seeing” the old {id: 10}?

You’ve been here before… 🤔

To quote the conclusion from the first half:

Each function within the component (including event handlers, effects, timers, or API calls, and so on) captures props and state in the render in which they were defined.

Now the answer is obvious. The effect cleanup does not read the “latest” props. It can only read props for the render in which it was defined:

Kingdoms will rise and return to dust, the sun will shed its outer layers into white dwarfs, and sooner or later the last civilizations will end. But the cleanup function for effect in the first render only sees the props {id: 10}.

This is why React handles effects immediately after drawing – and makes your application run more smoothly by default. You can still access the old props if your code needs to.

Synchronization, not life cycle

What I like most about React is that it uniformly describes the initial rendering and subsequent updates. This lowers the entropy of your program.

Let’s say I have a component that looks like this:

I render
and then
there is no difference between rendering
. In both cases, the last thing I saw was “Hello, Yuzhi”.

People always say, “It’s the journey, not the destination, that matters.” In the React world, the opposite is true. What matters is the end, not the process. This is the difference between a call (procedure) like $.addClass or $.removeclass in JQuery code and a declaration (purpose) of what the CSS class name should be in React code.

React will synchronize to the DOM based on our current props and state. There is no difference between “mount” and “update” for rendering.

You should think of Effects the same way. UseEffect allows you to synchronize things outside the React Tree based on props and state.

This is a subtle difference from the familiar mount/ Update /unmount mental model. It is important to understand and internalize this distinction. If you try to write an effect that behaves differently depending on whether it was first rendered, you are swimming against the tide. If our results depend on the process rather than the destination, we will make mistakes in synchronization.

Rendering attributes A, B and C is no different from rendering C immediately. While they may be slightly different for a short time (such as when requesting data), the end result is the same.

Then again, it might not be efficient to run all effects after every render. (And in some scenarios, it can cause an infinite loop.)

So how do we solve this problem?

Tell React to compare your Effects

We’ve already learned the solution from the way React handles the DOM. React only updates the parts of the DOM that actually change, rather than making a big deal out of every render.

When you take your

Update to the

React can see two objects:

It checks each of the props and finds that the DOM needs to be updated if the children changes, but the className does not. So it just needs to do this:

Can we do effects in a similar way? It would be nice to be able to avoid calling effect when you don’t need it.

For example, our component might be re-rendered due to a state change:

However, our effect does not use the state counter. Our effect will only synchronize the name property to document.title, but the name will not change. Reassigning document.title after every counter change is not ideal.

Okay, React can… Does it distinguish between effects?

And can’t. React can’t guess what the function is doing unless it’s called first. (The source code contains no special value, it simply refers to the name attribute.)

This is why if you want to avoid unnecessary repetition of effects calls, you can provide useEffect with a dependency array argument (deps) :

It’s like telling React: “Hey, I know you can’t see what’s in this function, but I can guarantee that only the render is usednameAnd nothing else.”

React will automatically skip this effect if the dependencies in the current render have the same values as the last time the effect was run, since there is nothing to synchronize:

Even if only one value in the dependency array is different between renderings, we cannot skip effect running. Sync all!

Don’t lie to React about dependencies

Lying to React about dependencies has bad consequences. Intuitively, this makes sense, but I’ve seen almost everyone who relies on the class mental model to use useEffect try to violate this rule. (I just did that!)

(websiteHooks FAQExplained what to do. We are inThe followingI’ll revisit this example.)

“But I just want to run it while it’s mounted!” “, you might say. Now just remember: if you set a dependency, all the values in the components used in Effect are included in the dependency. This includes props, state, functions-anything inside the component.

Sometimes you do, but that can cause a problem. For example, you might have problems with infinite requests, or sockets being created frequently. The solution is not to remove dependencies. We will know the specific solution soon.

But before we dive into the solution, let’s try to understand the problem better.

What happens if you set the wrong dependency?

If the dependency contains all the values used in Effect, React knows when to run it:

(The dependency has changed, so Effect is rerun.)

But if we set [] to an effect dependency, the new effect function will not run:

(The dependency has not changed, so Effect will not run again.)

In this example, the problem seems obvious. But in some cases if you “jump out” of the class component solution in your head, your intuition is likely to deceive you.

For example, let’s write a counter that increases every second. In the Class component, our intuition is “once on timer, once off timer”. Here’s an example of how to do it. When we translate it as useEffect as a matter of course, we intuitively set the dependency to []. “I only want to run effect once,” right?

However, this example will increment only once. Days and lulu.

If your mental model is “I only need to set dependencies when I want to re-trigger an effect”, this example might give you an existential crisis. You want to trigger once because it’s a timer — but why is that a problem?

You won’t be surprised if you know that dependencies are our cue to React, telling effect all the values in the render it needs to use. Effect uses count but we lie and say it has no dependency. If we do this sooner or later something will happen.

In the first rendering, count is 0. Therefore, setCount(count + 1) is equivalent to setCount(0 + 1) on the first rendering. Now that we have set the [] dependency, effect will not run again, and setCount(0 + 1) will be called every second after it:

We lied to React that our effect doesn’t depend on any values in the component, when in fact our effect does!

Our effect depends on count – it is the value inside the component (but defined outside effect) :

Therefore, setting [] to dependency introduces a bug. React compares dependencies and skips effects:

(The dependency has not changed, so Effect will not run again.)

It’s hard to think of a problem like this. Therefore, I encourage you to make it a hard and fast rule to tell Effect dependencies honestly, and to list all dependencies. (We provide a Lint rule if you want to enforce it within your team.)

Two ways to be honest about dependencies

There are two honest dependency strategies. You should start with the first and apply the second as needed.

The first strategy is to include values within all components used in effects in the dependency. Let’s include count in the dependency:

The dependency array is now correct. It may not be ideal but it does solve the above problem. Effect is now re-run every time count is changed, and setCount(count + 1) in the timer refers to the count value in the render correctly:

This will solve the problem but our timer will be cleared and reset every time the count changes. This should not be the result we want:

(The dependency has changed, so Effect is rerun.)

The second strategy is to modify the code inside Effect to ensure that it contains values that change only when needed. We don’t want to tell about bad dependencies – we just modify effects to make them less dependent.

Let’s look at some common techniques for removing dependencies.

Make Effects self-sufficient

We want to remove the count dependency on effect.

To do this, we need to ask ourselves a question: Why do we use count? You can see that we only use count in the setCount call. In this scenario, we don’t really need to use count in effect. When we want to update the state based on the previous state, we can use the function form of setState:

I like to call situations like this “false dependency.” Yes, count is a required dependency because we said setCount(count + 1) in Effect. But what we really want is to convert count to count+1 and then return to React. But React already knows the current count. The only thing we need to tell React is to increment the state – whatever it is now.

That’s exactly what setCount(c => c + 1) does. You can think of it as “sending instructions” to React on how to update the status. This “update form” also helps in other situations, such as when you need to batch update.

Note that we removed dependencies and did not lie. Our effect no longer reads in the rendercountValue.

(The dependency has not changed, so Effect will not run again.)

You can try it yourself.

Even though Effect only runs once, the timer callback in the first render works perfectly by sending React c => C + 1 updates every time it fires. It no longer needs to know the current count value. Because React already knows.

Functional updates and Google Docs

Remember we said synchronization is the mental model for understanding Effects? One of the interesting things about synchronization is that you often want to decouple the synchronized “information” from the state. For example, when you edit a document in Google Docs, Google doesn’t send the entire article to the server. That would be very inefficient. Instead, it simply sends your changes to the server in one form.

Although our case for effect is different, a similar idea can be applied. It would be helpful to pass only minimal information in Effects. An updated form like setCount(c => c + 1) passes less information than setCount(count + 1) because it is no longer “tainted” by the current count value. It simply expresses a behavior (” incremental “). “Thinking in React” also discusses how to find minimum states. The principles are similar, but now the focus is on updating.

Expressing intent (rather than results) is similar to how Google Docs handles co-editing. Although this analogy extends a bit, functional updates play a similar role in React. They ensure that state updates from various sources (event handlers, subscriptions in effects, and so on) can be handled in a batch and predictable manner.

However, even setCount(c => c + 1) is not perfect. It looks a little weird and is very limited in what it can do. For example, if we have two interdependent states, or if we want to calculate the next state based on a prop, it doesn’t do that. Fortunately, setCount(c => c + 1) has a more powerful sister mode, which is called useReducer.

Decouple updates from Actions

Let’s modify the above example to include two states: count and step. Our timer increments count one step at a time:

(Here’s demo.)

Notice we’re not lying. Since we use step in effect, we add it to the dependency. So that’s why the code works.

The current behavior of this example is that modifying step reboots the timer – because it is one of the dependencies. In most scenarios, this is exactly what you need. There is nothing wrong with clearing the previous effect and re-running the new effect. Unless we have a good reason, we should not change this default behavior.

However, if we don’t want to restart the timer after a step change, how do we remove our dependency on step from Effect?

When you want to update a status and the status update depends on the value of another status, you may need to use ituseReducerTo replace them.

When you write something like setSomething(something =>…) In this case, it may be time to consider using reducer. Reducer allows you to separate what is happening in the component (actions) from how the state is responding and updating.

We replace the Effect step dependency with a dispatch dependency:

(See demo.)

“How is this better?” you may ask. The answer is that React guarantees that dispatch will remain constant for the duration of the component’s declaration cycle. So there is no need to re-subscribe to the timer in the example above.

We solved the problem!

(You can remove dependenciesdispatch.setState, anduseRefThe values of the package because React ensures that they are static. But it’s okay if you set them up as dependencies.)

Instead of reading the state directly in effect, it dispatches an action that describes what happened. This decouples our effect and step states. Our Effect no longer cares about updating the state, it just tells us what’s going on. All the updated logic was sent to reducer for unified processing:

(Here’s the demo if you missed it.)

Why is useReducer a cheat mode for Hooks

We’ve learned how to remove the dependency of effects, whether state updates depend on one state or another. But what if we need to rely on props to calculate the next state? For example, maybe our API is
. To be sure, we can’t avoid relying on props. Step in this case. Isn’t it?

In fact, we can avoid it! We can put the Reducer function inside the component to read props:

This pattern invalidates some optimizations, so you should avoid abusing it, but you can always access the tools from the Reducer if you need to. (Here’s a demo.)

Even in this example React guarantees that the dispatch is the same on every render. So you can get rid of it in dependencies. It does not cause an effect to repeat itself unnecessarily.

You may be wondering: How is this possible? How does the reducer called in the previous rendering “know” the new props? The answer is that when you dispatch, React simply remembers the action – it will call the Reducer again in the next render. At that point, the new props can be accessed, and the reducer call is not in effect.

That’s why I tend to think, rightuseReducerIs “Cheat mode” from Hooks. It can separate the update logic from describing what happened. As a result, this helped me remove unnecessary dependencies and avoid unnecessary effect calls.

Let’s move this function into Effects

A typical misconception is that functions should not be dependencies. For example, the following code seems to work:

(This exampleAdapted from this great article by Robin Wieruch –Click to view!).

To be clear, the above code works. But doing so makes it difficult to ensure that it will work in all situations during iterations of increasingly complex components.

Imagine our code doing the following separation, and each function being five times larger:

Then we use some state or prop in some function:

If we forget to update the dependencies of effects that use these functions (most likely through other function calls), our effects won’t synchronize the changes to props and state. That’s certainly not what we want.

Fortunately, there is a simple solution to this problem. If some functions are called only in effect, you can move their definition to effect:

(Here’s demo.)

What’s the good of that? We no longer need to think about these “indirect dependencies”. Our dependency arrays don’t lie either: we really don’t use anything in the component scope anymore in our Effect.

If we later modify getFetchUrl to use the Query state, we are more likely to realize that we are editing it in effect – therefore, we need to add query to the effect dependency:

(Here’s demo.)

By adding this dependency, we’re not just “pleasing React.” It is reasonable to rerequest data after a Query change. UseEffect is designed to force you to pay attention to changes in the data stream and then decide how our effects should sync with it – rather than ignore it until our users run into bugs.

Thanks to the exhaustive depsLint rule of the eslint-plugin-react-hooks plugin, this will analyze effects as you code and provide suggestions for dependencies that might be missing. In other words, the machine tells you which data flow changes in the component were not handled correctly.

Very good.

But I can’t put this function in Effect

Sometimes you don’t want to move functions into effects. For example, if a component has several effects that use the same function, you don’t want to copy and paste this logic into each effect. Or maybe this function is a prop.

Should you ignore the function dependency in this case? I don’t think so. Again, efffects should not lie about its dependence. Often we have a better solution. A common misconception is that “functions never change”. But now that you’ve read this article, you know that’s obviously not true. In fact, the functions defined within the component change with each rendering.

The fact that the function changes every time it renders is a problem in itself. For example, two effects call getFetchUrl:

In this case, you probably don’t want to move getFetchUrl into Effects because you want to reuse the logic.

On the other hand, if you are “honest” about dependency, you may fall into a trap. Both of our effects depend on getFetchUrl, which is rendered differently each time, so our dependency array becomes useless:

One possible solution is to remove getFetchUrl from the dependency. But I don’t think this is a good solution. This makes future changes to the data flow harder to detect and forget to deal with. This causes a problem similar to the “timer does not update values” problem above.

Instead, there are two simpler solutions.

First, if a function doesn’t use any values in the component, you should define it outside of the component and then use it freely in Effects:

You no longer need to set them as dependencies because they are not in the render scope and therefore will not be affected by the data flow. It can’t suddenly and unexpectedly rely on props or state.

Alternatively, you can wrap it as useCallback Hook:

UseCallback essentially adds a layer of dependency checking. It solves the problem in a different way – we make the function itself change only when needed, rather than removing the dependency on the function.

Let’s see why this works. Previously, our example showed two types of search results (‘react’ and ‘redux’). But if we want to add an input field that allows you to enter any query you want. Instead of passing the Query argument, getFetchUrl now reads from the state.

We quickly discovered that it omitted the Query dependency:

If I add query to the useCallback dependency, any effect that calls getFetchUrl will be rerun if the query changes:

We have useCallback to thank, because if query remains unchanged, so will getFetchUrl, and our effect will not be rerun. But if query changes, getFetchUrl changes with it, so it rerequests the data. It’s like if you change the value of one cell in Excel, another cell that uses it will automatically recalculate.

This is the result of embracing data flow and synchronous thinking. This method also works for functions passed in from the parent component via attributes:

Because fetchData changes only when the Parent’s Query state changes, our Child will only re-request data when needed.

Is the function part of the data flow?

Interestingly, this pattern does not work in the Class component, and this failure perfectly illustrates the difference between effect and the lifecycle paradigm. Consider the following transformations:

You’re probably thinking, “Come on Dan, we all know useEffect is like componentDidMount and componentDidUpdate, and you can’t keep breaking that one!” Well, adding componentDidUpdate still doesn’t work:

Of course, fetchData is a class method! (Or you could say the class attribute — but that doesn’t change anything.) FetchData and prevProps. FetchData are always equal, so no request is rerequested. How about we delete the conditional judgment?

Wait, this will be requested after every render. (Adding a loading animation might be an interesting way to discover this.) Maybe we could bind to a specific Query?

But this.props. FetchData! The == prevProps. FetchData expression is always true, even if the query has not changed. This leads us to always ask.

The only realistic way to solve the problem in this class component is to force the Query itself into the Child component. The Child does not actually use the query value directly, but can trigger a re-request when it changes:

After using the React class component for so many years, I got so used to passing unnecessary props along and breaking the encapsulation of the parent component that I realized why I had to do it a week ago.

In a Class component, the function properties themselves are not part of the data flow. The inclusion of the mutable this variable in the component’s methods causes us to doubt that it is immutable. So, even if we only need one function, we have to pass a bunch of data around just to “diff”. We have no way of knowing whether the passed this.props. FetchData is dependent on the state, and whether its dependent state has changed.

With useCallback, functions can fully participate in the data flow. We can say that if the input of a function changes, the function changes. If not, the function doesn’t change. Thanks to the thoughtful useCallback, changes to properties like props. FetchData are also passed along automatically.

Similarly, useMemo allows us to do similar things with complex objects.

I want to emphasize that using a useCallback everywhere is a clumsy thing to do. UseCallback is a great technique and very useful when we need to pass a function along and it will be called in effect on a child component. Or if you’re trying to reduce the burden of memorizing subcomponents, try it. But in general, Hooks themselves do a better job of avoiding passing callback functions.

In the example above, I prefer to put fetchData in my effect (which can be detached into a custom Hook) or bring it in from the top level. I wanted to keep Effects simple, and calling callbacks inside would complicate things. (” What if a props. OnComplete callback changes and the request is still in progress?” ) You can simulate class behavior but that doesn’t solve the race problem.

Tell me about a race

Here is a typical example of making a request in a class component:

As you probably already know, the code above is hiding some problems. It doesn’t handle updates. So the second classic example you can find on the Internet is this:

That’s obviously better! But there are still problems. The reason for the problem is that the order in which the request results are returned is not guaranteed to be consistent. For example, I request {id: 10} first and then update to {id: 20}, but {id: 20} request comes back first. Requesting earlier but returning later incorrectly overwrites the status value.

This is called a race and is typical in code that mixes async/await (assuming waiting for results to return) with top-down data flow (the props and state may change during an async function call).

Effects does not magically solve this problem, although it will warn you if you pass an async function directly to Effect. (We will improve this warning to better explain these problems you may be experiencing.)

If you use an asynchronous mode that supports cancellation, great. You can cancel asynchronous requests directly in the cleanup function.

Or, the simplest expedient is to track it with a Boolean value:

This article discusses more about how to handle errors and load states, as well as pulling logic away from custom hooks. I recommend you do some reading if you want to learn more about how to request data in Hooks.

Improve the level of

In the class component lifecycle mindset, side effects behave differently than render outputs. UI rendering is powered by props and state and ensures consistency, but side effects are not. This is a common source of problems.

However, in the useEffect thinking model, all are synchronous by default. Side effects become part of the React data flow. For each useEffect call, once you handle it correctly, your component is better able to handle edge cases.

However, the upfront learning cost of using the useEffect well is higher. This can be irritating. Handling edge cases with synchronized code is naturally more difficult than triggering the side effect of not having to step in step with the rendering results once.

This is worrying if useEffect is the tool you use the most right now. At present, however, it is mostly still dealing with the low level of use. Hooks are so new that everyone still uses them at a low level, especially in some of the tutorial examples. But in practice, the community is likely to start using Hooks at a high level, because good apis have better momentum and momentum.

I see different applications creating their own Hooks, such as useFetch, which encapsulates the application authentication logic, or useTheme, which uses theme Context. Once you have a toolkit that includes these, you will not use useEffect directly as often. But every Hook based on it benefits from its ability to adapt.

So far, useEffect has been used mainly for data requests. But data requests are not exactly a synchronization issue. This is especially true because our dependence is often []. So what exactly are we synchronizing?

In the long run, Suspense for data requests will allow third party libraries to tell React to pause rendering in a first class way until something asynchronous (anything: code, data, images) is ready.

As Suspense gradually covers more data request usage scenarios, I expect useEffect to take a back seat as a powerful tool for synchronizing props and state to some side effects. Unlike data requests, it handles these scenarios well because that’s what it’s designed for. But until then, custom Hooks like the ones mentioned here are a good way to reuse data request logic.

In the end of the

Now that you know pretty much everything I know about how to use Effects, check out the TLDR at the beginning. Does it make sense to you now? Did I miss something? (I haven’t finished my paper yet!)

I’d love to hear what you think on Twitter. Thanks for reading.