# Fetching Data in React 🌐 Up to this point, most of the data in our [React](/courses/reactjs) examples has been written directly inside the application. For example: ```jsx id="gq7a1p" const products = [ { id: 1, name: "Laptop", price: 999 }, { id: 2, name: "Phone", price: 699 } ] ``` That works perfectly while learning. But real applications usually don't have all their data permanently sitting inside `App.jsx`. A real application may need to load: * products from an online store * posts from a blog API * messages from a server * GitHub profile information * weather data * dashboard statistics * orders from a database * search results * user account information That means our [React](/courses/reactjs) application needs to communicate with something outside itself. Usually: ```text id="rb4m8s" React App ↓ HTTP Request ↓ API / Server ↓ Response ↓ React State ↓ Updated UI ``` This process is usually called **data fetching**. And although calling an API looks simple at first... ```jsx id="cf2r9v" fetch("/api/products") ``` ...building a good data-fetching interface involves considerably more than "request data and display it." Because networks have the unfortunate habit of not behaving exactly how we'd like them to. 😌 --- # The Main Data-Loading States Whenever your interface loads remote data, you need to think about what the user should see **while the request is happening, after it succeeds, and when it fails**. The three fundamental states are: ```text id="pm5v8x" LOADING ↓ Request is still happening SUCCESS ↓ Request completed successfully ERROR ↓ Something went wrong ``` A basic UI might therefore behave like this: ```text id="zc7m2f" Loading ↓ "Loading posts..." Success ↓ Show the posts Error ↓ "Could not load posts" [ Retry ] ``` This is one of the most important habits to build when working with APIs. Don't design only the happy path. The internet does not owe your component a successful `200 OK`. 😂 --- # There Are Often More Than Three UI States Loading, success, and error are the core request states, but real interfaces frequently need two additional situations. The first is **idle**. Imagine a GitHub search page: ```text id="wv9q4b" [ Enter username... ] [ Search ] ``` Before the user searches, nothing is loading and nothing has failed. That's an idle state. The second is **empty success**. Suppose the request succeeds perfectly but returns: ```jsx id="dr3n7p" [] ``` Technically: ```text id="qt8m1c" Success ✅ ``` But showing a completely blank screen would be confusing. The UI should probably say: ```text id="nk5r9v" No posts found. ``` So a more realistic mental model is: ```text id="hx2m6z" Idle ↓ Loading ↓ ┌─────────────┐ │ │ Success Error │ ├── Data available │ └── Empty result ``` You won't need every state in every component, but you should consciously think about them. --- # What Is an API? Before we start fetching, let's make sure the terminology makes sense. An **API** is a way for one piece of software to communicate with another. For example, your React application may request: ```text id="bf7q3j" https://example.com/api/products ``` The server might respond with JSON: ```json id="yu4m8k" [ { "id": 1, "name": "Laptop", "price": 999 }, { "id": 2, "name": "Phone", "price": 699 } ] ``` Your React application receives that data and stores it in state. Then JSX renders it. So: ```text id="ej6p2w" API ↓ JSON data ↓ React receives it ↓ State stores it ↓ JSX displays it ``` That's the basic relationship. --- # Native `fetch()` Modern browsers provide a built-in [function](/javascript/functions-in-javascript) called: ```jsx id="kx9r5a" fetch() ``` You don't need to install a package to use it. A very simple request looks like: ```jsx id="mc3v7h" const response = await fetch( "https://example.com/api/products" ) ``` `fetch()` returns a Promise that eventually gives us a `Response`. Then we can read the response body. For JSON: ```jsx id="za8q4n" const data = await response.json() ``` So a basic request might look like: ```jsx id="rp5m2x" async function loadProducts() { const response = await fetch( "https://example.com/api/products" ) const data = await response.json() console.log(data) } ``` But this version is missing error handling. And error handling is where things become interesting. --- # `fetch()` Does Not Throw for Every HTTP Error This catches many beginners. Suppose the server responds with: ```text id="hv7n3c" 404 Not Found ``` or: ```text id="sj4q8m" 500 Internal Server Error ``` You might assume: ```jsx id="fd9r2v" await fetch(...) ``` automatically throws an error. It doesn't for normal HTTP error responses. `fetch()` generally resolves with a `Response` even for statuses such as `404` or `500`; you need to inspect something such as `response.ok` or `response.status` yourself. That's why this check is important: ```jsx id="cw6m1p" if (!response.ok) { throw new Error( `Request failed: ${response.status}` ) } ``` `response.ok` is `true` for successful HTTP statuses in the `200–299` range. A good basic pattern is therefore: ```jsx id="tn8q5k" const response = await fetch(url) if (!response.ok) { throw new Error( `Request failed: ${response.status}` ) } const data = await response.json() ``` --- # Fetching Data When a Component Appears One common beginner example is loading data when a component first appears. Because a network request synchronizes the component with something outside React, an Effect can be used for this. Let's build a posts page. ```jsx id="mq3r7f" import { useEffect, useState } from "react" function PostsList() { const [posts, setPosts] = useState([]) const [loading, setLoading] = useState(true) const [error, setError] = useState(null) useEffect(() => { async function loadPosts() { try { setLoading(true) setError(null) const response = await fetch( "https://jsonplaceholder.typicode.com/posts?_limit=5" ) if (!response.ok) { throw new Error( `Failed to load posts (${response.status})` ) } const data = await response.json() setPosts(data) } catch (error) { setError(error.message) } finally { setLoading(false) } } loadPosts() }, []) if (loading) { return (

Loading posts...

) } if (error) { return (

Error: {error}

) } return (

{post.title}

{post.body.slice(0, 100)} ...

) } ``` There are several concepts working together here, so let's break them down. --- # State for the Data First: ```jsx id="gp6n2d" const [posts, setPosts] = useState([]) ``` stores the actual API data. Before the request finishes: ```jsx id="fy9m4b" posts = [] ``` After a successful request, it may become: ```jsx id="wd3q7v" [ { id: 1, title: "...", body: "..." }, { id: 2, title: "...", body: "..." } ] ``` That state controls what the interface eventually displays. --- # State for Loading We also have: ```jsx id="ra5n8x" const [loading, setLoading] = useState(true) ``` Initially, the request hasn't finished. So: ```text id="kq2m6p" loading = true ``` and the component displays: ```jsx id="vc8r3h"

Loading posts...

``` Once the request finishes: ```jsx id="bn7q4m" setLoading(false) ``` and React can display either the data or an error. --- # State for Errors We also store: ```jsx id="xt5p9c" const [error, setError] = useState(null) ``` `null` means: ```text id="hz3m7r" No error currently ``` If something fails: ```jsx id="pj8q2v" setError(error.message) ``` the component can render useful feedback. For example: ```jsx id="mw6n4a" if (error) { return (

Error: {error}

) } ``` Without an error state, users often see: ```text id="ec9r5k" Loading... ``` forever. Which is not technically an error message, but after 45 seconds it begins to feel like one. 😭 --- # Understanding `try`, `catch`, and `finally` Our request uses: ```jsx id="sv4q8n" try { // request } catch (error) { // failure } finally { // always run } ``` The `try` block contains code that may fail: ```jsx id="ga7m3x" try { const response = await fetch(url) // ... } ``` If an error is thrown, [JavaScript](/courses/javascript) jumps into: ```jsx id="dy2p6f" catch (error) { ``` where we can store the error. Then: ```jsx id="nr8q4c" finally { setLoading(false) } ``` runs after either success or failure. That makes `finally` convenient for ending the loading state. So: ```text id="wb5m9j" Request begins ↓ setLoading(true) ↓ try / \ Success Error \ / finally ↓ setLoading(false) ``` --- # Why the Effect Callback Itself Shouldn't Be `async` You may be tempted to write: ```jsx id="kt3q7m" useEffect(async () => { const response = await fetch(url) }, []) ``` Avoid this pattern. An Effect callback is expected to return either nothing or a cleanup [function](/javascript/functions-in-javascript). An `async` function automatically returns a Promise instead, which doesn't match the Effect cleanup contract. That's why the common pattern is: ```jsx id="ap9n5v" useEffect(() => { async function loadData() { // await here } loadData() }, []) ``` The Effect itself stays synchronous, while the inner function can use `await`. React's own documentation uses this style when demonstrating manual [async](/javascript/promises-asynchronous-javascript) fetching from an Effect. --- # Add an Empty State Too Our first example should really handle another possibility. What if: ```jsx id="fs6m2r" posts = [] ``` because the API successfully returned zero posts? Instead of showing: ```jsx id="pn4q8x"

``` we can write: ```jsx id="cr7m3h" if (posts.length === 0) { return (

No posts found.

) } ``` Now the UI distinguishes: ```text id="xk5r9v" Loading Error Success with data Success with no data ``` That's much more useful to the person using the application. --- # A Better Fetch-on-Mount Example Let's improve the original example by handling cancellation and an empty response too. ```jsx id="vb2n6q" import { useEffect, useState } from "react" function PostsList() { const [posts, setPosts] = useState([]) const [loading, setLoading] = useState(true) const [error, setError] = useState(null) useEffect(() => { const controller = new AbortController() async function loadPosts() { try { setLoading(true) setError(null) const response = await fetch( "https://jsonplaceholder.typicode.com/posts?_limit=5", { signal: controller.signal } ) if (!response.ok) { throw new Error( `Failed to load posts (${response.status})` ) } const data = await response.json() setPosts(data) } catch (error) { if ( error.name !== "AbortError" ) { setError(error.message) } } finally { if ( !controller.signal.aborted ) { setLoading(false) } } } loadPosts() return () => { controller.abort() } }, []) if (loading) { return (

Loading posts...

) } if (error) { return (

Couldn't load posts

{error}

) } if (posts.length === 0) { return (

No posts found.

) } return (

{post.title}

{post.body.slice( 0, 100 )} ...

) } ``` Now we're handling the network request more carefully. We'll explain `AbortController` properly later in this chapter. --- # Fetching Because the User Did Something Not every request should happen inside `useEffect`. This connects directly to what we learned earlier about Effects. If the request exists because: > "The component appeared and needs to synchronize with this remote data" an Effect can make sense. But if the request happens because: > "The user clicked Search" then the event handler is usually the natural place to perform it. For example: ```text id="hm8q3f" User clicks Search ↓ handleSubmit() ↓ fetch(...) ``` We don't need to change some state purely so that an Effect notices and performs the request. --- # GitHub User Search 🔍 Let's build a useful example. ```jsx id="qy4m7c" import { useState } from "react" function GitHubUserSearch() { const [username, setUsername] = useState("") const [user, setUser] = useState(null) const [loading, setLoading] = useState(false) const [error, setError] = useState(null) async function handleSearch( event ) { event.preventDefault() const cleanUsername = username.trim() if (!cleanUsername) { return } setLoading(true) setError(null) setUser(null) try { const response = await fetch( `https://api.github.com/users/${encodeURIComponent( cleanUsername )}` ) if (!response.ok) { if ( response.status === 404 ) { throw new Error( `User "${cleanUsername}" was not found.` ) } throw new Error( `Request failed (${response.status})` ) } const data = await response.json() setUser(data) } catch (error) { setError(error.message) } finally { setLoading(false) } } return (

{error && (

❌ {error}

)} {user && (

{user.name || user.login}

{user.bio && (

{user.bio}

)}

Followers:{" "} {user.followers}

Public repositories:{" "} {user.public_repos}

)}

) } ``` Notice that there's no Effect here. That's intentional. The request belongs directly to the form submission. --- # Following the Search Flow Before the user searches: ```text id="gp7m2x" username = "" user = null loading = false error = null ``` That's the **idle state**. Then the user searches: ```text id="zw5q9b" username = "octocat" ``` We call: ```jsx id="fn3r8v" setLoading(true) setError(null) setUser(null) ``` The UI changes to: ```text id="kc6m1p" Searching... ``` Then either the request succeeds: ```text id="ua8q4n" API response ↓ setUser(data) ``` or fails: ```text id="hr2m7c" Error ↓ setError(...) ``` Finally: ```jsx id="jd9q5v" setLoading(false) ``` ends the loading state. This is a clean example of state representing the actual request lifecycle. --- # Why Clear the Previous Error? Suppose the user searches for: ```text id="sx4n8k" definitely-not-a-user ``` and gets: ```text id="rp7m3f" User not found. ``` Then they search again for a real account. If you never run: ```jsx id="nw2q6d" setError(null) ``` the old error may remain visible while the new request is happening. That's misleading. So when starting a fresh request, it's common to reset state that belongs to the previous attempt: ```jsx id="vm8r4h" setLoading(true) setError(null) ``` Whether you also clear old successful data depends on the user experience you want. --- # Should Old Data Disappear During Refetching? This is an interesting design decision. You could do: ```jsx id="bx5m9c" setUser(null) setLoading(true) ``` which removes the old result immediately. Or you could keep the old result visible while showing something like: ```text id="qf3r7v" Refreshing... ``` Many polished applications distinguish between: ```text id="zt8m2k" Initial loading ``` and: ```text id="hc6q4n" Background refreshing ``` For a beginner example, clearing the data is simple. For production applications, keeping stale data visible while fetching newer data can often create a smoother experience. This is one of the many reasons dedicated data-fetching libraries become useful later. --- # Better Error Messages This: ```jsx id="yr7m3c" setError( "Something went wrong" ) ``` is better than showing nothing. But errors can be more useful when they explain what the user can do. Instead of: ```text id="ka9q5v" Something went wrong. ``` consider: ```text id="mv2n8h" We couldn't load your posts. Check your connection and try again. [ Retry ] ``` A good error UI often contains: ```text id="rc6m4p" What went wrong + What the user can do next ``` Don't punish users by making them diagnose your HTTP request from a blank page. 😭 --- # Fetching With Axios Another popular way to make HTTP requests is **Axios**. Unlike `fetch`, Axios is an external package, so you install it: ```bash id="vg8q3m" npm install axios ``` Then: ```jsx id="tp5m9r" import axios from "axios" ``` Axios gives you convenience features around HTTP requests, including response transformation, configurable defaults, interceptors, request cancellation, and error handling. That does **not** mean Axios is automatically better than `fetch`. Modern `fetch()` is already very capable and built into browsers. The choice depends on your application and team. --- # A Simple Axios Request With `fetch`, we might write: ```jsx id="zn3q7c" const response = await fetch(url) if (!response.ok) { throw new Error(...) } const data = await response.json() ``` With Axios: ```jsx id="hp8m2v" const response = await axios.get(url) const data = response.data ``` Or destructure it: ```jsx id="wf5q9b" const { data } = await axios.get(url) ``` Axios responses expose the response payload through `response.data`, along with information such as `status`, `headers`, and configuration. --- # Axios and HTTP Errors By default, Axios rejects requests for response statuses outside its accepted success range, so a typical request can be handled with `try/catch`. ```jsx id="nd2r6f" try { const { data } = await axios.get(url) setUsers(data) } catch (error) { // handle error } ``` Axios error objects may provide a server response through: ```jsx id="jm7q4x" error.response ``` and server response data through: ```jsx id="bk3m8c" error.response?.data ``` when the request reached the server and it responded with an unsuccessful status. --- # Users Page With Axios ```jsx id="qr9m5v" import axios from "axios" import { useEffect, useState } from "react" function UsersPage() { const [users, setUsers] = useState([]) const [loading, setLoading] = useState(true) const [error, setError] = useState(null) useEffect(() => { const controller = new AbortController() async function loadUsers() { try { setLoading(true) setError(null) const { data } = await axios.get( "https://jsonplaceholder.typicode.com/users", { signal: controller.signal } ) setUsers(data) } catch (error) { if ( error.code !== "ERR_CANCELED" ) { const message = error.response?.data ?.message || error.message || "Unable to load users." setError(message) } } finally { if ( !controller.signal.aborted ) { setLoading(false) } } } loadUsers() return () => { controller.abort() } }, []) if (loading) { return (

Loading users...

) } if (error) { return (

Error: {error}

) } if (users.length === 0) { return (

No users found.

) } return (

{user.name} {" — "} {user.email}

) } ``` Axios supports `AbortController` through the `signal` option, so request cancellation can follow a similar pattern to native `fetch`. --- # `fetch` vs Axios You don't need to treat this like a programming religion. Both can make HTTP requests. ### Native `fetch` Advantages include: * built into modern browsers * no extra dependency * based on web standards * supports `AbortController` * perfectly capable for many applications But you manually handle things such as: ```jsx id="vs4q8n" response.ok response.json() ``` depending on the response you expect. ### Axios Advantages include conveniences such as: * `response.data` * default handling of unsuccessful HTTP statuses through rejection * configurable Axios instances * interceptors * request/response configuration * convenient shared API configuration For example: ```jsx id="mc7r3h" const api = axios.create({ baseURL: "https://api.example.com" }) ``` can be useful in applications making many requests to the same backend. Neither option automatically makes your application well-designed. You can write terrible API code with either one. A comforting reminder that libraries cannot save us from ourselves. 😌 --- # Which Should Beginners Learn First? Learn native `fetch()` first. Why? Because it teaches you the actual browser API concepts: ```text id="nx5m9k" Request Response HTTP status JSON parsing Promises async / await AbortController ``` Once those concepts make sense, Axios becomes very easy to understand. Then you can choose Axios when its conveniences are useful rather than because someone on YouTube said: > "Real developers don't use fetch." Real developers mostly use whatever solves the problem their team actually has. 😂 --- # Cancelling a Request With `AbortController` Imagine a component starts loading: ```text id="bt3q7m" /api/products ``` but before the request finishes, the component is removed. Or maybe the user changes: ```text id="pw8m2v" userId = 10 ``` to: ```text id="zg4n6c" userId = 20 ``` before the first request finishes. The earlier request may no longer be relevant. The browser provides: ```jsx id="hq7m3f" AbortController ``` to cancel supported [asynchronous](/javascript/promises-asynchronous-javascript) operations such as `fetch()`. --- # Creating an Abort Controller ```jsx id="km5q9v" const controller = new AbortController() ``` The controller contains a signal: ```jsx id="dc2r6n" controller.signal ``` Pass that signal to `fetch`: ```jsx id="rx8m4h" const response = await fetch( "/api/data", { signal: controller.signal } ) ``` Then cancel it: ```jsx id="vj3q7c" controller.abort() ``` When a fetch is aborted, it rejects with an `AbortError`. --- # Cancellation Inside an Effect ```jsx id="fp9m5b" useEffect(() => { const controller = new AbortController() async function loadData() { try { const response = await fetch( "/api/data", { signal: controller.signal } ) if (!response.ok) { throw new Error( `Request failed (${response.status})` ) } const data = await response.json() setData(data) } catch (error) { if ( error.name !== "AbortError" ) { setError(error.message) } } } loadData() return () => { controller.abort() } }, []) ``` The cleanup: ```jsx id="wy6n2d" return () => { controller.abort() } ``` cancels that request when the Effect becomes obsolete. That can happen when the component unmounts or when dependencies change and React cleans up the previous Effect. --- # Cancellation Is About More Than "Memory Leaks" Older tutorials often say: > "Abort requests to prevent memory leaks." That's an incomplete explanation. One of the more important problems is **stale requests and race conditions**. Suppose the user quickly changes from: ```text id="sa8q4n" User A ``` to: ```text id="bn5m9c" User B ``` We start: ```text id="rt3q7v" Request A Request B ``` You might assume A finishes first. Networks do not respect narrative order. Maybe: ```text id="jc6m2p" Request B finishes ↓ Show User B Request A finishes later ↓ Oops — show User A again ``` Now your UI contains old data. React's documentation specifically discusses cleanup for fetches as a way to cancel or ignore outdated work and avoid these race conditions. --- # Race Condition Example Imagine: ```jsx id="mv8r4h" useEffect(() => { async function loadUser() { const response = await fetch( `/api/users/${userId}` ) const data = await response.json() setUser(data) } loadUser() }, [userId]) ``` Now the user changes: ```text id="xz5m9k" userId: 1 → 2 → 3 ``` Three requests may be in flight. If the response order becomes: ```text id="qf3r7v" Request 3 Request 2 Request 1 ``` the final state could incorrectly contain User `1`. That's why cancellation or stale-response protection matters. --- # Fetching Whenever a Dependency Changes Sometimes data depends on a prop. For example: ```jsx id="hc6q4n" function UserProfile({ userId }) { ``` Then: ```jsx id="jp2m8x" useEffect(() => { // load current user }, [userId]) ``` makes sense. Whenever: ```text id="zw7q3c" userId changes ``` the component needs different remote data. A proper version might be: ```jsx id="vr5m9b" useEffect(() => { const controller = new AbortController() async function loadUser() { try { setLoading(true) setError(null) const response = await fetch( `/api/users/${userId}`, { signal: controller.signal } ) if (!response.ok) { throw new Error( "Could not load user" ) } const data = await response.json() setUser(data) } catch (error) { if ( error.name !== "AbortError" ) { setError(error.message) } } finally { if ( !controller.signal.aborted ) { setLoading(false) } } } loadUser() return () => { controller.abort() } }, [userId]) ``` Now when `userId` changes, React cleans up the old request before synchronizing with the new user ID. --- # Retrying Failed Requests 🔄 A good error state often includes a Retry button. The first instinct might be: ```jsx id="dk8m4h" const [ retryCount, setRetryCount ] = useState(0) useEffect(() => { fetchData() }, [retryCount]) ``` Then: ```jsx id="mt5q9v" ``` This works. Changing `retryCount` causes the Effect to run again. But it introduces state whose only job is: > "Please make my Effect happen again." For many components, we can write something clearer. --- # A Cleaner Retry Pattern We can move the loading function outside the Effect: ```jsx id="rw3n7c" async function loadData() { // request } ``` Then call it: ```jsx id="xp8m2f" useEffect(() => { loadData() }, []) ``` and from the Retry button: ```jsx id="qb5m9v" ``` However, when Effects and cancellation are involved, you need to design this carefully so requests can still be cancelled correctly. For a simple teaching example, let's build a request that happens on demand instead. --- # Retry Example ```jsx id="sv7q3n" import { useEffect, useState } from "react" function DataWithRetry() { const [data, setData] = useState(null) const [loading, setLoading] = useState(false) const [error, setError] = useState(null) async function loadData() { try { setLoading(true) setError(null) const response = await fetch( "/api/data" ) if (!response.ok) { throw new Error( `Request failed (${response.status})` ) } const result = await response.json() setData(result) } catch (error) { setError(error.message) } finally { setLoading(false) } } useEffect(() => { loadData() }, []) if (loading) { return (

) } if (error) { return (

❌ {error}

) } if (!data) { return null } return (

      {JSON.stringify(
        data,
        null,
        2
      )}

) } ``` Conceptually: ```text id="fn4m8k" Initial load ↓ loadData() Request fails ↓ Show error ↓ User clicks Retry ↓ loadData() ↓ Try again ``` In a more production-oriented implementation, you'd also coordinate request cancellation and repeated clicks. --- # Disable Actions While a Request Is Running Suppose a user clicks: ```text id="kj6m2p" Submit ``` seven times because nothing visually happened during the first 400 milliseconds. Congratulations. Your server may now receive seven requests. 😭 Loading state isn't only useful for displaying text. It can also prevent duplicate actions. For example: ```jsx id="gr9q5v" ``` Now the button communicates what's happening and prevents repeated submissions. This is much better UX. --- # Spinner vs Skeleton vs Text A loading state doesn't always need a giant animated spinner. For very small interactions: ```text id="vw3n7c" Loading... ``` may be enough. For content-heavy screens, a **skeleton** can often feel smoother: ```text id="mp8m2f" ┌─────────────────────────┐ │ ██████████████ │ │ ██████████████████████ │ │ ████████████ │ └─────────────────────────┘ ``` For button actions: ```text id="qr5m9v" Saving... ``` is often more useful than hiding the entire screen behind a spinner. The right loading UI depends on what is being loaded. The important thing is that the user understands: > "The application received my action and is doing something." --- # Don't Hide Existing Data Unnecessarily Imagine a dashboard already displaying information. The user clicks: ```text id="dy7q3n" Refresh ``` You could immediately replace everything with: ```text id="fx4m8k" LOADING... ``` But sometimes it's better to keep the existing data visible: ```text id="bc6m2p" Dashboard data still visible Refreshing... 🔄 ``` This distinction is often described as: ```text id="zr9q5v" Initial Loading vs Background Refetching ``` Good data-fetching libraries often model these situations separately. It's one of the reasons loading state becomes more nuanced as applications grow. --- # Don't Forget Validation of the Response A successful HTTP request does not automatically mean the data has the shape your application expects. Suppose you expect: ```jsx id="hj3n7c" { id: 1, name: "Alice" } ``` but the server returns: ```jsx id="km8m2f" { banana: true } ``` Technically: ```text id="pq5m9v" HTTP 200 ✅ ``` but your application may still be unable to use that response safely. In larger applications, validating API responses with schemas or [TypeScript](/courses/typescript)-based runtime validation can become useful. For now, simply understand: > **HTTP success and valid application data are related, but they are not exactly the same thing.** That's a more advanced concern, but worth remembering. --- # Should You Fetch Data Directly Inside `useEffect`? For learning React and for simple client-side applications: ```jsx id="sy7q3n" useEffect(() => { // fetch data }, []) ``` is useful and valid. It teaches you: * Effects * loading state * async functions * errors * cleanup * race conditions * cancellation But manual Effect fetching has limitations. React's documentation points out that fetching directly in Effects can make caching, server rendering, request deduplication, and avoiding network waterfalls harder. For larger applications, framework data-loading APIs or client-side caching libraries are often better choices. So don't turn this chapter into the rule: ```text id="fw4m8k" Need data? ↓ useEffect + fetch ↓ FOREVER ``` Instead: ```text id="ac6m2p" Learning / small SPA ↓ fetch + Effect can be fine Larger application ↓ Consider framework loaders or dedicated data cache/library ``` --- # React Router and Data Fetching You learned [React Router](/courses/reactjs) earlier. Modern [React Router](/courses/reactjs)'s Data and Framework modes can load route data through the routing layer instead of manually starting every page request inside `useEffect`. Conceptually: ```text id="nr9q5v" User navigates to route ↓ Router loads route data ↓ Page receives data ↓ UI renders ``` That approach can be cleaner for page-level data because routing and data requirements are closely connected. You don't need to abandon everything in this chapter. Understanding manual `fetch()` is still important. Framework tools are much easier to understand once you know what they're doing for you. --- # Data Libraries Another approach is using a dedicated client-side data library. Popular tools can handle concerns such as: ```text id="gx3n7c" Caching Refetching Retries Deduplication Stale data Background refresh Request status Pagination ``` instead of manually rebuilding those systems for every component. Again, the progression should be: ```text id="tz8m2f" Learn fetch ↓ Understand request lifecycle ↓ Understand errors/cancellation ↓ Then appreciate what libraries automate ``` Otherwise you end up with: ```jsx id="mp5m9v" const { data, isPending } = useMagicQuery(...) ``` and absolutely no idea what problem the magic is solving. 😂 --- # Common Beginner Mistakes 🚨 ## Mistake 1: Handling Only Success This: ```jsx id="cq7m3h" const data = await fetch(...) setPosts(data) ``` isn't enough. Think about: ```text id="vf2n6q" Loading? Error? Empty? Success? ``` Every visible state matters. --- # Mistake 2: Forgetting `response.ok` Wrong: ```jsx id="bk9m5c" const response = await fetch(url) const data = await response.json() setData(data) ``` because a `404` response doesn't automatically mean `fetch()` rejects. Better: ```jsx id="rx3q7v" const response = await fetch(url) if (!response.ok) { throw new Error( `Request failed (${response.status})` ) } const data = await response.json() ``` --- # Mistake 3: Making the Effect Callback `async` Avoid: ```jsx id="hm8m2k" useEffect(async () => { const data = await fetchData() }, []) ``` Use: ```jsx id="tz5q9b" useEffect(() => { async function loadData() { const data = await fetchData() } loadData() }, []) ``` The Effect setup function needs to preserve React's cleanup contract. --- # Mistake 4: Fetching a User Action Through an Unnecessary Effect You don't need: ```text id="fn3r7c" Button clicked ↓ setShouldFetch(true) ↓ Effect notices state ↓ fetch() ``` when this works: ```jsx id="qp8m2v" async function handleClick() { await fetch(...) } ``` If the user interaction causes the request, put the request in the event handler when appropriate. --- # Mistake 5: Ignoring Stale Requests This: ```jsx id="cw5m9n" useEffect(() => { fetch(`/api/users/${userId}`) .then(...) }, [userId]) ``` can produce race conditions if `userId` changes quickly. Use cancellation or another stale-response strategy when requests can overlap. --- # Mistake 6: Showing Loading Forever After an Error If you write: ```jsx id="zr7q3h" try { // request setLoading(false) } catch (error) { setError(error.message) } ``` then failure never calls: ```jsx id="jx2n6q" setLoading(false) ``` A `finally` block is often useful: ```jsx id="pm9m5c" finally { setLoading(false) } ``` because it runs in both paths. --- # Mistake 7: Treating Axios as Required You don't need Axios just because you're building a "real" React application. Native: ```jsx id="dv3q7v" fetch() ``` is perfectly legitimate. Axios is another tool with useful conveniences. Choose it when those conveniences are useful. --- # Mistake 8: Calling Everything a Memory Leak If a request continues after the component has moved on, the main concerns may include: * wasted network work * outdated responses * race conditions * unwanted state updates * stale UI Cleanup is important, but saying: ```text id="hk8m2f" No AbortController ↓ MEMORY LEAK!!! ``` oversimplifies what's actually happening. Understand the lifecycle instead. --- # A Complete Practical Example: Product Search 🛍️ Let's combine the concepts. ```jsx id="wx5m9v" import { useState } from "react" function ProductSearch() { const [query, setQuery] = useState("") const [products, setProducts] = useState([]) const [loading, setLoading] = useState(false) const [error, setError] = useState(null) const [hasSearched, setHasSearched] = useState(false) async function handleSubmit( event ) { event.preventDefault() const cleanQuery = query.trim() if (!cleanQuery) { return } setLoading(true) setError(null) setHasSearched(true) try { const response = await fetch( `/api/products?q=${encodeURIComponent( cleanQuery )}` ) if (!response.ok) { throw new Error( "Unable to search products." ) } const data = await response.json() setProducts(data) } catch (error) { setProducts([]) setError(error.message) } finally { setLoading(false) } } return (

{!hasSearched && (

Search for a product to get started.

)} {error && (

❌ {error}

)} {!loading && !error && hasSearched && products.length === 0 && (

No matching products were found.

)} {!loading && !error && products.length > 0 && (

{product.name}

)}

) } ``` This component recognizes multiple states. --- # Understanding the Product Search States Before the first search: ```text id="tr7q3n" hasSearched = false loading = false ``` The UI says: ```text id="jc4m8k" Search for a product to get started. ``` That's idle. While searching: ```text id="pm6m2p" loading = true ``` The button says: ```text id="yr9q5v" Searching... ``` If the server fails: ```text id="df3n7c" error = "Unable to search products." ``` the user sees an error and retry option. If the request succeeds but: ```jsx id="gh8m2f" products = [] ``` the UI says: ```text id="zx5m9v" No matching products were found. ``` And if data exists: ```jsx id="np7q3h" products.length > 0 ``` the list renders. That is a much more complete data-fetching UI. --- # Request State as a Mental Model 🧠 Don't think only in terms of: ```text id="kc2n6q" fetch() ↓ data ``` Think: ```text id="rw8m4h" REQUEST │ ┌──────┴──────┐ │ │ Loading Finished │ ┌──────┴──────┐ │ │ Success Failure │ ┌─────┴─────┐ │ │ Data Empty ``` Then ask: > "What should the user see at every point in this diagram?" That question produces much better applications. --- # Quick `fetch()` Cheat Sheet 🚀 Basic request: ```jsx id="vm5q9b" const response = await fetch(url) ``` Check HTTP status: ```jsx id="sf3r7v" if (!response.ok) { throw new Error( `Request failed (${response.status})` ) } ``` Parse JSON: ```jsx id="bx8m2f" const data = await response.json() ``` Handle failure: ```jsx id="pk6m2p" try { // request } catch (error) { setError(error.message) } ``` Stop loading: ```jsx id="qz9q5v" finally { setLoading(false) } ``` Cancel a request: ```jsx id="jc3n7c" const controller = new AbortController() fetch(url, { signal: controller.signal }) controller.abort() ``` Ignore intentional abort errors: ```jsx id="mw8m2f" if ( error.name !== "AbortError" ) { setError(error.message) } ``` --- # Quick Axios Cheat Sheet Install: ```bash id="vx5m9v" npm install axios ``` Import: ```jsx id="tr7q3c" import axios from "axios" ``` GET request: ```jsx id="kn2n6q" const { data } = await axios.get(url) ``` Error handling: ```jsx id="pq8m4h" try { const { data } = await axios.get(url) } catch (error) { console.log( error.response?.data || error.message ) } ``` Cancel with a signal: ```jsx id="rf6m2p" const controller = new AbortController() axios.get(url, { signal: controller.signal }) controller.abort() ``` --- # Chapter Summary 🎯 Fetching data isn't only about writing: ```jsx id="yn9q5v" fetch(url) ``` A good data-fetching interface needs to represent the entire request lifecycle. The fundamental states are: ```text id="dc3n7c" Loading Success Error ``` But depending on the interface, you may also need: ```text id="hp8m2f" Idle Empty Refreshing ``` Your UI should clearly communicate what's happening. For native `fetch()`: ```jsx id="qw5m9v" const response = await fetch(url) ``` remember that unsuccessful HTTP status codes such as `404` don't automatically make the Promise reject. Check: ```jsx id="nr7q3c" if (!response.ok) { throw new Error(...) } ``` Then parse the body: ```jsx id="km2n6q" const data = await response.json() ``` For loading/error handling: ```jsx id="xp8m4h" try { setLoading(true) // request } catch (error) { setError(error.message) } finally { setLoading(false) } ``` When a request exists because the component needs to synchronize with remote data, an Effect may make sense. ```jsx id="bc6m2p" useEffect(() => { // load remote data }, [dependency]) ``` When a request exists because the user performed an action: ```text id="zr9q5v" clicked Search submitted form pressed Refresh ``` the event handler is often the better place to perform the request. Use `AbortController` when requests may become obsolete: ```jsx id="jf3n7c" const controller = new AbortController() ``` pass: ```jsx id="kw8m2f" signal: controller.signal ``` and clean up with: ```jsx id="pv5m9v" controller.abort() ``` This helps stop obsolete work and protects your interface from stale requests and race conditions. Axios is another valid HTTP client: ```jsx id="sr7q3c" const { data } = await axios.get(url) ``` It provides several conveniences, but it isn't automatically superior to `fetch()`. So the bigger mental model is: ```text id="hn2n6q" Start request ↓ Show loading state ↓ Perform request ↓ Check result / \ Success Failure ↓ ↓ Store Store data error \ / ↓ ↓ Stop loading ↓ Render the correct UI ``` And don't forget that successful requests can still return no useful results: ```text id="rm8m4h" Request succeeded ↓ data.length === 0 ↓ Show useful empty state ``` The goal isn't simply to make the API call work. The goal is to make the **interface behave well whether the network succeeds, fails, takes five seconds, returns nothing, or gets replaced by a newer request**. Once you start thinking that way, you're no longer just fetching data. You're designing asynchronous UI. And yes, that's a much fancier phrase for: > "The server is taking a while. What should I show meanwhile?" 😂 --- # Keep Learning With asif.to 🚀 Your React application can now communicate with real external data sources, which is a major step. You've moved from: ```text id="tq5m9v" const users = [...] ``` to: ```text id="wn7q3c" React ↓ API Request ↓ Server ↓ Response ↓ State ↓ Dynamic UI ``` And all the concepts you've already learned now start working together: ```text id="kc2n6q" Components 🧩 Display different parts of the interface State 🧠 Stores data, loading, and errors Events ⚡ Trigger searches, saves, and refreshes Effects 🔄 Synchronize with remote data when appropriate Lists 📋 Render API collections Conditions 🤔 Display loading, errors, empty states, and results React Router 🧭 Can connect route changes with data requirements ``` The best practice projects for this chapter are things that force you to handle more than the successful response. Build a GitHub profile search, movie search, products page, users directory, weather viewer, or posts page. Then deliberately break the request URL and make sure the error state still feels like part of the application rather than an afterthought. Also test: ```text id="yp8m4h" Loading Error Retry No results Successful results Multiple searches Slow responses ``` If all of those experiences feel reasonable, you're thinking about data fetching properly. For more beginner-friendly React lessons, API examples, and practical web development explanations, visit **asif.to**. Follow **asif.to** on its social handles too for shorter React tips, API examples, and programming explanations that teach why the code exists instead of dropping `fetch()` into a component and declaring victory. 😄 **Don't build only for the successful request. Networks fail. Users retry. Good interfaces are ready for both. 🚀** — **asif.to**

{post.title}

Couldn't load posts

{post.title}

{user.name || user.login}