Fetching data

A product page that waits for the server

Most pages show data that lives on a server: a product, a list of orders, a profile. The page can't have it when it first appears. It has to ask, wait, and show the answer when it comes. In React, the simplest place to ask is an effect. Here is a product page that does it. Its server is pretend: the api.js tab answers after a delay, like a real one would, and nothing goes over the network. The result is live; press Run again to watch it load.

1import { useEffect, useState } from "react";2import { fetchProduct } from "./api.js";3 4export default function ProductPage() {5  const [product, setProduct] = useState(null);6 7  useEffect(() => {8    console.log("Fetch tea");9    fetchProduct("tea").then((data) => {10      console.log("Show tea");11      setProduct(data);12    });13  }, []);14 15  if (product === null) return <p>Loading…</p>;16  return <h2>{product.name}: ${product.price}</h2>;17}

Line 5 keeps the product in state, starting as null: nothing has arrived yet. On the first render, line 15 sees null and shows Loading…. After React has put that on the screen, it runs the effect on lines 7 to 13. Line 9 calls fetchProduct("tea"), which returns a promise: a value that arrives later. In the api.js tab, line 4 says tea takes 1500 ms. When the answer comes, line 11 stores it with setProduct. That causes a second render, and this time line 16 shows Green tea: $3. The empty array on line 13 says the effect has nothing to react to, so it runs when the page first appears.

Open the console under the result. It says Fetch tea and Show tea with a small 2 beside each: the effect ran twice. That's StrictMode, which every example here runs in, as a new project does. In development only, it runs each new effect, cleans it up, and runs it again, to check that the cleanup works. This one has no cleanup, so both requests answer. You fix that in a moment.

Why the request goes in an effect

A fetch is a side effect: it reaches outside the component, to a server. React asks that rendering stays a pure calculation of the screen (Keeping components pure explains why), because React may call your component many times. So this is wrong, on purpose:

function ProductPage() {
  const [product, setProduct] = useState(null);
  // Wrong: this line runs on every render.
  fetchProduct("tea").then((data) => setProduct(data));
  return <h2>{product?.name}</h2>;
}

Line 4 runs on every render. The first render asks for tea. When the answer comes, setProduct causes a second render, which asks for tea again, whose answer causes a third render, and so on: a request every 1.5 seconds, for as long as the page is open. It isn't live here for that reason. An effect runs after React has shown the page, and only again when one of its dependencies changes.

You may want to write the effect itself as an async function. That doesn't work either:

useEffect(async () => {
  const data = await fetchProduct("tea");
  setProduct(data);
}, []);

An async function always returns a promise. React expects an effect to return a cleanup function or nothing, so in development it prints useEffect must not return anything besides a function, which is used for clean-up. Worse, React keeps the promise as if it were the cleanup, and calls it when the cleanup is due. Calling a promise throws an error, which in development reads TypeError: destroy is not a function (destroy is React's own name for a cleanup). StrictMode cleans up every new effect at once, so in development the page breaks as soon as it appears. Instead, write an async function inside the effect and call it:

1import { useEffect, useState } from "react";2import { fetchProduct } from "./api.js";3 4export default function ProductPage() {5  const [product, setProduct] = useState(null);6 7  useEffect(() => {8    async function load() {9      console.log("Fetch tea");10      const data = await fetchProduct("tea");11      setProduct(data);12    }13    load();14  }, []);15 16  if (product === null) return <p>Loading…</p>;17  return <h2>{product.name}: ${product.price}</h2>;18}

Lines 8 to 12 define load, which can use await on line 10. Line 13 calls it. The effect function itself stays a normal function that returns nothing, so React is happy, and you can still add a cleanup with return. Both styles, .then and await, do the same thing; the rest of this lesson uses whichever reads better.

Switch quickly and the wrong product wins

Real pages change what they ask for: a product picker, a tab, a search box. Here the page can switch between two products. In api.js, cake answers after 300 ms and tea after 1500 ms.

1import { useEffect, useState } from "react";2import { fetchProduct } from "./api.js";3 4export default function ProductPage() {5  const [productId, setProductId] = useState("cake");6  const [product, setProduct] = useState(null);7 8  useEffect(() => {9    console.log(`Fetch ${productId}`);10    fetchProduct(productId).then((data) => {11      console.log(`Show ${productId}`);12      setProduct(data);13    });14  }, [productId]);15 16  return (17    <>18      <button onClick={() => setProductId("tea")}>Tea</button>19      <button onClick={() => setProductId("cake")}>Cake</button>20      <p>Picked: {productId}</p>21      {product ? <h2>{product.name}: ${product.price}</h2> : <p>Loading…</p>}22    </>23  );24}

Line 5 keeps which product is picked, and line 6 the product that arrived. The effect on lines 8 to 14 lists productId in its dependencies, so it runs again whenever you pick another product, and asks for that one. Click Tea, then Cake straight away. The page shows Picked: cake and Carrot cake, and then, about a second later, it switches to Green tea: $3, though cake is still picked. The console says why: Fetch tea, Fetch cake, Show cake, Show tea.

That's a race condition: two requests race, and whichever answers last wins, not the one you asked for last. Nothing on line 12 knows that tea is no longer wanted. You met this bug with a search box in You might not need an effect; any effect that fetches for a value that can change has it. The playground runs this page with three ways to write its effect. Each bar is one request, from the moment the effect starts it to its end.

With No cleanup, click Tea then Cake: the tea bar ends last and turns red, shown, but it's not the one you picked. Try clicking Cake then Tea instead: nothing goes wrong, because the slow request is also the newest. That's what makes race conditions hard to find: they depend on timing. Then choose ignore flag and click Tea, Cake again.

1import { useEffect, useState } from "react";2import { fetchProduct } from "./api.js";3 4export default function ProductPage() {5  const [productId, setProductId] = useState("cake");6  const [product, setProduct] = useState(null);7 8  useEffect(() => {9    let ignore = false;10    console.log(`Fetch ${productId}`);11    fetchProduct(productId).then((data) => {12      if (ignore) {13        console.log(`Ignore ${productId}`);14        return;15      }16      console.log(`Show ${productId}`);17      setProduct(data);18    });19    return () => {20      ignore = true;21    };22  }, [productId]);23 24  return (25    <>26      <button onClick={() => setProductId("tea")}>Tea</button>27      <button onClick={() => setProductId("cake")}>Cake</button>28      <p>Picked: {productId}</p>29      {product ? <h2>{product.name}: ${product.price}</h2> : <p>Loading…</p>}30    </>31  );32}

Line 9 makes a flag, ignore, for this run of the effect. Lines 19 to 21 return the cleanup: React calls it before it runs the effect again for a new productId, and when the page leaves the screen. It sets this run's flag to true. When an answer arrives, lines 12 to 15 check the flag of the run that asked, and drop the answer if that run was cleaned up. Click Tea, then Cake: the console ends with Show cake and Ignore tea, and the page stays on cake.

Why does each answer see the right flag? Every run of the effect is a new call of the effect function, with its own let ignore. The then callback on line 11 remembers the ignore of the call that made it: a closure. Look at the console from the first run too: Fetch cake twice, then Ignore cake and Show cake. StrictMode's check cleaned up the first run, and the cleanup did its job.

Cancel the old request with AbortController

The ignore flag throws the old answer away, but the old request still runs to the end. When it's a big download, or the server does real work for it, you can stop it instead. The browser's tool for that is an AbortController (the Cancellation lesson covers it in full). It has two parts:

• controller.signal, which you pass to the request. fetch accepts it as fetch(url, { signal }), and the pretend fetchProduct in api.js does too (lines 12 to 15).
• controller.abort(), which cancels it. The request stops, and its promise rejects with an error named AbortError.

1import { useEffect, useState } from "react";2import { fetchProduct } from "./api.js";3 4export default function ProductPage() {5  const [productId, setProductId] = useState("cake");6  const [product, setProduct] = useState(null);7 8  useEffect(() => {9    const controller = new AbortController();10    console.log(`Fetch ${productId}`);11    fetchProduct(productId, { signal: controller.signal })12      .then((data) => {13        console.log(`Show ${productId}`);14        setProduct(data);15      })16      .catch((error) => {17        if (error.name === "AbortError") console.log(`Cancelled ${productId}`);18      });19    return () => {20      controller.abort();21    };22  }, [productId]);23 24  return (25    <>26      <button onClick={() => setProductId("tea")}>Tea</button>27      <button onClick={() => setProductId("cake")}>Cake</button>28      <p>Picked: {productId}</p>29      {product ? <h2>{product.name}: ${product.price}</h2> : <p>Loading…</p>}30    </>31  );32}

Line 9 makes a controller for this run, and line 11 passes its signal to fetchProduct. The cleanup on lines 19 to 21 aborts it. A cancelled request never answers, so the then on line 12 can't run for it; instead, its promise rejects, and the catch on lines 16 to 18 runs. An AbortError isn't a real failure, so line 17 only logs it. Click Tea, then Cake: the console says Fetch tea, Fetch cake, Cancelled tea, Show cake. In the playground, choose AbortController: the tea bar now stops the moment you click Cake.

How to read the table: each row is one question, answered for each way of cleaning up.

Use an AbortController when the request accepts a signal, as fetch does. Use an ignore flag for anything else, like a library function that can't be cancelled. Either way, the rule is the same: an effect that fetches needs a cleanup.

Loading and error states

So far, a page with no product yet showed Loading…, and a failure would show nothing at all. A real page has three states: still loading, done, or failed. Keeping them in one piece of state, with a status, means the page can never be loading and failed at once (Choosing the state structure explains why one object beats several flags). This server fails sometimes: in its api.js, line 13 makes the first request for the scone fail, like a busy server.

1import { useEffect, useState } from "react";2import { fetchProduct } from "./api.js";3 4const menu = ["cake", "tea", "scone"];5 6export default function ProductPage() {7  const [productId, setProductId] = useState("cake");8  const [attempt, setAttempt] = useState(1);9  const [result, setResult] = useState({ status: "loading" });10 11  useEffect(() => {12    let ignore = false;13    fetchProduct(productId)14      .then((product) => {15        if (!ignore) setResult({ status: "done", product });16      })17      .catch((error) => {18        if (!ignore) setResult({ status: "error", message: error.message });19      });20    return () => {21      ignore = true;22    };23  }, [productId, attempt]);24 25  function pick(id) {26    setProductId(id);27    setResult({ status: "loading" });28  }29 30  function retry() {31    setAttempt(attempt + 1);32    setResult({ status: "loading" });33  }34 35  return (36    <>37      {menu.map((id) => (38        <button key={id} disabled={id === productId} onClick={() => pick(id)}>{id}</button>39      ))}40      {result.status === "loading" && <p>Loading…</p>}41      {result.status === "error" && <p>{result.message} <button onClick={retry}>Retry</button></p>}42      {result.status === "done" && <h2>{result.product.name}: ${result.product.price}</h2>}43    </>44  );45}

Line 9 starts the result as { status: "loading" }. The effect on lines 11 to 23 stores either { status: "done", product } (line 15) or { status: "error", message } (line 18), and keeps the ignore flag from before. Lines 40 to 42 show one line for each status.

Two event handlers put the page back to loading. pick on lines 25 to 28 changes the product and sets the status in the same click, so the old product never shows under the new name. retry on lines 30 to 33 adds one to attempt. attempt is in the effect's dependencies on line 23, so a new number runs the effect again, which asks again. Click scone: after 0.7 seconds, The server is busy. Try again. appears with a Retry button. Press it, and the second request works: Cheese scone: $2.

With a real server, there's one more thing to check. fetch only rejects when no answer comes back at all, like when you're offline. An answer that says "404 Not Found" or "500 Server Error" still resolves, with response.ok set to false (fetch covers it). So a real fetchProduct checks it and throws, which sends the page to its error state:

export async function fetchProduct(id, { signal } = {}) {
  const response = await fetch(`/api/products/${id}`, { signal });
  if (!response.ok) {
    throw new Error(`The server answered ${response.status}.`);
  }
  return response.json();
}

Line 2 passes the signal on to fetch, so it can be cancelled. Line 3 checks response.ok, and line 4 turns a bad answer into an error. Line 6 reads the answer as JSON. It isn't live because these examples never call a real server.

Waterfalls: requests that wait in line

Pages are made of components, and each one can fetch what it needs. That's tidy, but it can make requests wait for each other. Here a product page shows its reviews with a Reviews component (in the Reviews.jsx tab), which fetches them in its own effect. The api.js tab notes the time of every request and answer in the console.

1import { useEffect, useState } from "react";2import { fetchProduct } from "./api.js";3import Reviews from "./Reviews.jsx";4 5export default function ProductPage() {6  const [product, setProduct] = useState(null);7 8  useEffect(() => {9    let ignore = false;10    fetchProduct("tea").then((data) => {11      if (!ignore) setProduct(data);12    });13    return () => {14      ignore = true;15    };16  }, []);17 18  if (product === null) return <p>Loading…</p>;19  return (20    <>21      <h2>{product.name}: ${product.price}</h2>22      <Reviews productId="tea" />23    </>24  );25}

Line 18 returns Loading… until the product arrives, and only after that, line 22 renders Reviews. A component's effect runs after it renders, so the reviews request can't start until the product has arrived. The console shows it: 0 ms: ask for product tea, 800 ms: product tea arrived, then 800 ms: ask for reviews tea, and 1500 ms: reviews tea arrived. (Each line has a 2 beside it: StrictMode again. The times are a little later in your browser than here, because the page takes a moment to start.)

This is a request waterfall: each request waits for the one before, like water falling from one step to the next. The reviews don't need anything from the product, so the wait is pure loss. The fix is to render Reviews at once:

1import { useEffect, useState } from "react";2import { fetchProduct } from "./api.js";3import Reviews from "./Reviews.jsx";4 5export default function ProductPage() {6  const [product, setProduct] = useState(null);7 8  useEffect(() => {9    let ignore = false;10    fetchProduct("tea").then((data) => {11      if (!ignore) setProduct(data);12    });13    return () => {14      ignore = true;15    };16  }, []);17 18  return (19    <>20      {product === null ? <p>Loading…</p> : <h2>{product.name}: ${product.price}</h2>}21      <Reviews productId="tea" />22    </>23  );24}

Line 20 now shows Loading… or the product in place, and line 21 renders Reviews right away. Both components render in the first commit, both effects run, and both requests start at 0 ms. The reviews arrive at 700 ms and the product at 800 ms: the page is complete at 800 ms instead of 1500.

Waterfalls also hide inside one effect, as two awaits in a row (exercise 5 has one), where Promise.all starts both at once (Sequential vs parallel explains it). Some waterfalls are real, though: if the reviews needed a sellerId that only the product's answer has, the second request must wait. In the browser, the only way round that is to ask the server for both in one request, or to let the server do the waiting, close to the data, which is what frameworks do.

What an effect can't do for you

Everything so far works, and it's worth knowing how it works. But look at how much code the product page needed for one request: a status, a flag or a controller, a cleanup, a retry counter. React's own documentation recommends a framework or a data library for real apps, because fetching in effects has costs that the code above doesn't fix:

• No cache. In the loading and error example, pick tea, wait, pick cake, then tea again. Tea shows Loading… for 1.5 seconds again: every visit asks the server again, and nothing remembers the last answer.
• No sharing. Two components that need the same product each send their own request.
• Nothing on the server. Effects only run in the browser. A page built on the server (Server rendering and hydration covers it) sends HTML that only says Loading…, and the browser starts asking after its JavaScript has loaded.
• Waterfalls. Each component asks only once it renders, as the last section showed.
• Repeated code. Every component that fetches needs the same cleanup and status. You could move them into a custom hook of your own, as in Reusing logic with custom hooks, but caching and sharing are still yours to build.

A framework like Next.js or React Router loads a page's data before rendering it, often on the server, and can start several requests at once. A data library like TanStack Query or SWR keeps a cache of answers, shares requests between components, and handles old answers, loading, and errors. Here is the product page with TanStack Query, as a sketch: the examples here don't install it, so it isn't live.

import { useQuery } from "@tanstack/react-query";
import { fetchProduct } from "./api.js";

function ProductPage({ productId }) {
  const { data, error, isPending } = useQuery({
    queryKey: ["product", productId],
    queryFn: () => fetchProduct(productId),
  });
  if (isPending) return <p>Loading…</p>;
  if (error) return <p>{error.message}</p>;
  return <h2>{data.name}: ${data.price}</h2>;
}

Lines 5 to 8 ask the library for the product. queryKey on line 6 names the answer in the cache, so a second visit to the same product, or a second component asking for it, gets the saved answer. queryFn on line 7 is the same fetchProduct as before. Lines 9 to 11 read the status the library keeps. There's no effect, no flag, and no cleanup in your code. The Data fetching libraries lesson covers how they work.

How to read the table: each row is a situation, with what happens with an effect and with a framework or library.

One more thing an effect can't do: tell React that part of the page is waiting. Each component above draws its own Loading…. Suspense, the next lesson, lets you describe loading states for a whole part of the page in one place, and frameworks plug their data into it.

A product page that handles all of it

Here is everything together: a product picker that cancels old requests, a status for loading, done, and error with a retry, and reviews that load at the same time as the product. The Reviews.jsx tab cancels its own request the same way.

1import { useEffect, useState } from "react";2import { fetchProduct } from "./api.js";3import Reviews from "./Reviews.jsx";4 5const menu = ["cake", "tea", "scone"];6 7export default function ProductPage() {8  const [productId, setProductId] = useState("cake");9  const [attempt, setAttempt] = useState(1);10  const [result, setResult] = useState({ status: "loading" });11 12  useEffect(() => {13    const controller = new AbortController();14    fetchProduct(productId, { signal: controller.signal })15      .then((product) => setResult({ status: "done", product }))16      .catch((error) => {17        if (error.name === "AbortError") return;18        setResult({ status: "error", message: error.message });19      });20    return () => {21      controller.abort();22    };23  }, [productId, attempt]);24 25  function pick(id) {26    setProductId(id);27    setResult({ status: "loading" });28  }29 30  function retry() {31    setAttempt(attempt + 1);32    setResult({ status: "loading" });33  }34 35  return (36    <>37      {menu.map((id) => (38        <button key={id} disabled={id === productId} onClick={() => pick(id)}>{id}</button>39      ))}40      {result.status === "loading" && <p>Loading…</p>}41      {result.status === "error" && <p>{result.message} <button onClick={retry}>Retry</button></p>}42      {result.status === "done" && <h2>{result.product.name}: ${result.product.price}</h2>}43      <Reviews key={productId} productId={productId} />44    </>45  );46}

Lines 12 to 23 are the effect: a controller per run (line 13), its signal passed on (line 14), and abort() in the cleanup (line 21). Line 17 skips the AbortError from a cancelled request, so only real failures reach the error state on line 18. Line 43 renders Reviews next to the product, not after it, so both requests start together. Its key gives each product a fresh Reviews, with its own null to start from, as Preserving and resetting state shows. Click tea, then scone, then cake, quickly: only cake and its review arrive. Click scone and wait for the error, then press Retry.

Common mix-ups

• "A quick fetch can go straight in the component body." No. The body runs on every render, and the answer's setState causes another render, which fetches again. Fetch in an effect or an event handler.
• "useEffect(async () => …) is a shorter way to write it." No. It returns a promise instead of a cleanup. React warns, and then breaks the page when it tries to call that promise as the cleanup. Put an async function inside the effect and call it.
• "Race conditions only happen on slow networks." No. They happen whenever answers can arrive in a different order than you asked, which a server can do on any network. In the playground, the server is local and it still happens.
• "The cleanup only matters when the component leaves the page." No. React also calls it before every re-run of the effect, which is exactly when the old request needs to be dropped.
• "fetch rejects when the server answers 404 or 500." No. It resolves with response.ok set to false. Check it, and throw.
• "Seeing every request twice means my app sends two requests in production." No. StrictMode runs new effects twice in development only, to check your cleanup. With a cleanup, the first answer is dropped or cancelled.
• "Suspense will show its fallback while my effect loads." No. Suspense doesn't know about requests in effects. The next lesson shows what it does see.

Practice exercises

Each exercise has a live result: click in it, change the code with Edit & run, and open the console to see the requests. Run again starts the pretend server from scratch.

import { useEffect, useState } from "react";
import { fetchProduct } from "./api.js";

export default function ProductPage() {
  const [productId, setProductId] = useState("cake");
  const [product, setProduct] = useState(null);

  useEffect(() => {
    console.log(`Fetch ${productId}`);
    fetchProduct(productId).then((data) => {
      console.log(`Show ${productId}`);
      setProduct(data);
    });
  }, [productId]);

  return (
    <>
      <button onClick={() => setProductId("tea")}>Tea</button>
      <button onClick={() => setProductId("cake")}>Cake</button>
      <p>Picked: {productId}</p>
      {product ? <h2>{product.name}: ${product.price}</h2> : <p>Loading…</p>}
    </>
  );
}

1import { useEffect, useState } from "react";2import { fetchProduct } from "./api.js";3 4export default function ProductPage() {5  const [productId, setProductId] = useState("cake");6  const [product, setProduct] = useState(null);7 8  useEffect(() => {9    console.log(`Fetch ${productId}`);10    fetchProduct(productId).then((data) => {11      console.log(`Show ${productId}`);12      setProduct(data);13    });14  }, [productId]);15 16  return (17    <>18      <button onClick={() => setProductId("tea")}>Tea</button>19      <button onClick={() => setProductId("cake")}>Cake</button>20      <p>Picked: {productId}</p>21      {product ? <h2>{product.name}: ${product.price}</h2> : <p>Loading…</p>}22    </>23  );24}

1import { useEffect, useState } from "react";2import { fetchProduct } from "./api.js";3 4export default function ProductPage() {5  const [product, setProduct] = useState(null);6 7  useEffect(() => {8    let ignore = false;9    fetchProduct("tea").then((data) => {10      if (!ignore) setProduct(data);11    });12    return () => {13      ignore = true;14    };15  }, []);16 17  return product && <h2>{product.name}: ${product.price}</h2>;18}

1import { useEffect, useState } from "react";2import { fetchProduct } from "./api.js";3 4export default function ProductPage() {5  const [product, setProduct] = useState(null);6 7  useEffect(() => {8    let ignore = false;9    fetchProduct("tea").then((data) => {10      if (!ignore) setProduct(data);11    });12    return () => {13      ignore = true;14    };15  }, []);16 17  if (product === null) return <p>Loading…</p>;18  return <h2>{product.name}: ${product.price}</h2>;19}

1import { useEffect, useState } from "react";2import { fetchDelivery } from "./api.js";3 4export default function DeliveryEstimate() {5  const [city, setCity] = useState("paris");6  const [estimate, setEstimate] = useState("");7 8  useEffect(() => {9    fetchDelivery(city).then((text) => {10      setEstimate(text);11    });12  }, [city]);13 14  return (15    <>16      <button onClick={() => setCity("london")}>London</button>17      <button onClick={() => setCity("paris")}>Paris</button>18      <p>Deliver to: {city}</p>19      <p>{estimate}</p>20    </>21  );22}

1import { useEffect, useState } from "react";2import { fetchDelivery } from "./api.js";3 4export default function DeliveryEstimate() {5  const [city, setCity] = useState("paris");6  const [estimate, setEstimate] = useState("");7 8  useEffect(() => {9    let ignore = false;10    fetchDelivery(city).then((text) => {11      if (!ignore) setEstimate(text);12    });13    return () => {14      ignore = true;15    };16  }, [city]);17 18  return (19    <>20      <button onClick={() => setCity("london")}>London</button>21      <button onClick={() => setCity("paris")}>Paris</button>22      <p>Deliver to: {city}</p>23      <p>{estimate}</p>24    </>25  );26}

1import { useEffect, useState } from "react";2import { fetchProduct } from "./api.js";3 4const menu = ["cake", "scone"];5 6export default function ProductPage() {7  const [productId, setProductId] = useState("cake");8  const [product, setProduct] = useState(null);9 10  useEffect(() => {11    let ignore = false;12    fetchProduct(productId).then((data) => {13      if (!ignore) setProduct(data);14    });15    return () => {16      ignore = true;17    };18  }, [productId]);19 20  function pick(id) {21    setProductId(id);22    setProduct(null);23  }24 25  return (26    <>27      {menu.map((id) => (28        <button key={id} disabled={id === productId} onClick={() => pick(id)}>{id}</button>29      ))}30      {product ? <h2>{product.name}: ${product.price}</h2> : <p>Loading…</p>}31    </>32  );33}

1import { useEffect, useState } from "react";2import { fetchProduct } from "./api.js";3 4const menu = ["cake", "scone"];5 6export default function ProductPage() {7  const [productId, setProductId] = useState("cake");8  const [product, setProduct] = useState(null);9  const [error, setError] = useState(null);10 11  useEffect(() => {12    let ignore = false;13    fetchProduct(productId)14      .then((data) => {15        if (!ignore) setProduct(data);16      })17      .catch((reason) => {18        if (!ignore) setError(reason.message);19      });20    return () => {21      ignore = true;22    };23  }, [productId]);24 25  function pick(id) {26    setProductId(id);27    setProduct(null);28    setError(null);29  }30 31  return (32    <>33      {menu.map((id) => (34        <button key={id} disabled={id === productId} onClick={() => pick(id)}>{id}</button>35      ))}36      {error && <p>{error}</p>}37      {!error && (product ? <h2>{product.name}: ${product.price}</h2> : <p>Loading…</p>)}38    </>39  );40}

1import { useEffect, useState } from "react";2import { fetchDelivery, fetchOrder } from "./api.js";3 4export default function OrderPage() {5  const [page, setPage] = useState(null);6 7  useEffect(() => {8    let ignore = false;9    async function load() {10      const order = await fetchOrder();11      const delivery = await fetchDelivery();12      if (!ignore) setPage({ order, delivery });13    }14    load();15    return () => {16      ignore = true;17    };18  }, []);19 20  if (page === null) return <p>Loading your order…</p>;21  return <p>Order {page.order.id}: {page.order.items} items, arriving {page.delivery}</p>;22}

1import { useEffect, useState } from "react";2import { fetchDelivery, fetchOrder } from "./api.js";3 4export default function OrderPage() {5  const [page, setPage] = useState(null);6 7  useEffect(() => {8    let ignore = false;9    async function load() {10      const [order, delivery] = await Promise.all([fetchOrder(), fetchDelivery()]);11      if (!ignore) setPage({ order, delivery });12    }13    load();14    return () => {15      ignore = true;16    };17  }, []);18 19  if (page === null) return <p>Loading your order…</p>;20  return <p>Order {page.order.id}: {page.order.items} items, arriving {page.delivery}</p>;21}

1import { useEffect, useState } from "react";2import { fetchDelivery } from "./api.js";3 4export default function DeliveryEstimate() {5  const [city, setCity] = useState("paris");6  const [estimate, setEstimate] = useState("");7 8  useEffect(() => {9    let ignore = false;10    fetchDelivery(city).then((text) => {11      if (!ignore) setEstimate(text);12    });13    return () => {14      ignore = true;15    };16  }, [city]);17 18  return (19    <>20      <button onClick={() => setCity("london")}>London</button>21      <button onClick={() => setCity("paris")}>Paris</button>22      <p>Deliver to: {city}</p>23      <p>{estimate}</p>24    </>25  );26}

1import { useEffect, useState } from "react";2import { fetchDelivery } from "./api.js";3 4export default function DeliveryEstimate() {5  const [city, setCity] = useState("paris");6  const [estimate, setEstimate] = useState("");7 8  useEffect(() => {9    const controller = new AbortController();10    fetchDelivery(city, { signal: controller.signal })11      .then((text) => setEstimate(text))12      .catch((error) => {13        if (error.name === "AbortError") console.log(`Cancelled ${city}`);14      });15    return () => {16      controller.abort();17    };18  }, [city]);19 20  return (21    <>22      <button onClick={() => setCity("london")}>London</button>23      <button onClick={() => setCity("paris")}>Paris</button>24      <p>Deliver to: {city}</p>25      <p>{estimate}</p>26    </>27  );28}

Check your understanding

For each question about timing, write down when each request starts and when it answers, then ask which setState runs last.

Key takeaways

• Fetch in an effect, not while rendering, and store the answer in state. The first render shows a loading state.
• Don't make the effect function async. Define an async function inside it and call it.
• When the thing you fetch can change, answers can arrive out of order. Clean up every run: an ignore flag drops the old answer, and an AbortController cancels the old request.
• Keep one status for loading, done, and error. Check response.ok, because fetch doesn't reject on 404 or 500.
• A child that renders only after its parent's data starts its request late: a waterfall. Render independent parts together.
• Effects have no cache, no sharing, and nothing on the server. Real apps use a framework or a data library for that.

Coming next: Suspense. It lets a part of the page wait for its code or data, and shows a loading state you describe once, around it.