Fetching Data

Data usually lives somewhere else: a database behind an API, a search service, another team's endpoint. Getting it into a component is a request across a network, which means it takes time, it can fail, and the answer can arrive after you have stopped caring about the question.

There are two places to make that request. In a Next.js application, the first choice is a server component, which fetches before any HTML is sent and needs no state, no effect and no loading flag. The second is an effect in a client component, which is what you need when the request depends on something the user is doing right now.

This lesson covers both, and spends most of its time on the failure that only appears when requests overlap.

// app/employees/page.tsx — a server component. No hooks involved.
interface Employee {
  id: string;
  name: string;
  department: string;
}

async function getEmployees(): Promise<Employee[]> {
  const response = await fetch("https://api.example.com/employees", {
    headers: { Authorization: "Bearer " + process.env.DIRECTORY_API_TOKEN },
    next: { revalidate: 300 },
  });

  if (!response.ok) {
    throw new Error("Employee directory request failed: " + response.status);
  }

  return response.json();
}

export default async function EmployeesPage() {
  const employees = await getEmployees();
  return <EmployeeTable employees={employees} />;
}

• The component is an async function and awaits the data. Next.js waits for it before sending HTML, so the page arrives with the employees already in it.
• There is no loading state here because there is no moment when the component is rendered without data. That is the main reason to prefer this shape when the data does not depend on client-side interaction.
• The API token is read from an environment variable on the server. This code never reaches the browser, so the token is not exposed — which is a property of where the component runs, and the deployment lesson explains the rules around it.
• next: { revalidate: 300 } asks Next.js to cache the result for five minutes. The caching lesson goes into what that means and when it is the wrong choice.
• Throwing on a failed response hands the problem to the nearest error boundary rather than rendering a page built from undefined. The Loading and Error States lesson covers what the user then sees.

"use client";

import { useEffect, useState } from "react";

// Looks reasonable. Has a race condition.
export function EmployeeSearchResults({ term }: { term: string }) {
  const [results, setResults] = useState<Employee[]>([]);

  useEffect(() => {
    async function load() {
      const response = await fetch("/api/employees?q=" + encodeURIComponent(term));
      const data = await response.json();
      setResults(data);
    }
    load();
  }, [term]);

  return <EmployeeTable employees={results} />;
}

• The effect depends on term, so it re-runs whenever the search term changes. That part is right.
• encodeURIComponent is not optional. A term containing an ampersand or a hash would otherwise change the meaning of the URL.
• What is missing is any handling of the previous request. Each keystroke starts a new one, and nothing stops an earlier one from finishing later and calling setResults with its own data.

"use client";

import { useEffect, useState } from "react";

export function EmployeeSearchResults({ term }: { term: string }) {
  const [results, setResults] = useState<Employee[]>([]);
  const [error, setError] = useState<string | null>(null);

  useEffect(() => {
    // Cancels the request itself when this effect is cleaned up.
    const controller = new AbortController();
    // Belt and braces: ignore a response that resolves during teardown.
    let ignore = false;

    async function load() {
      try {
        const response = await fetch("/api/employees?q=" + encodeURIComponent(term), {
          signal: controller.signal,
        });
        if (!response.ok) throw new Error("Search failed: " + response.status);
        const data: Employee[] = await response.json();
        if (!ignore) {
          setResults(data);
          setError(null);
        }
      } catch (caught) {
        // An aborted request is expected, not a failure to report.
        if (caught instanceof Error && caught.name === "AbortError") return;
        if (!ignore) setError("Could not load results. Try again.");
      }
    }

    load();

    return () => {
      ignore = true;
      controller.abort();
    };
  }, [term]);

  if (error) return <p role="alert">{error}</p>;
  return <EmployeeTable employees={results} />;
}

• The cleanup runs before the effect runs again. So by the time the second request starts, the first has been aborted and its ignore flag is set — whatever it does afterwards cannot reach state.
• ignore is declared inside the effect, so each run has its own. That is what makes it work: the variable belongs to one request, not to the component.
• Aborting makes fetch reject with an AbortError. Catching it and returning is important, or every keystroke logs an error that is not one.
• Checking response.ok matters because fetch resolves normally for a 404 or a 500. Only a network-level failure rejects, so without this check you would parse an error page as JSON.
• The same cleanup covers unmounting. Navigate away mid-request and the response arrives to a component that no longer exists, and without the guard you are setting state on nothing.