Solution

You'll wrap an asynchronous request in state, kicking it off in an effect and recording whether it is still running, what it returned, or how it failed.

The problem, in plain English

A component asks for data — a user profile, a list of orders — and the answer doesn't arrive instantly. In that gap the component needs to show something: a spinner while it waits, the data once it lands, an error message if the request blows up. Those are three distinct states, and a request moves from the first into exactly one of the other two. useQuery owns that little state machine. You give it a function that returns a Promise; it runs the function, watches the Promise, and reports back { data, error, isLoading } so your component can just describe what each state looks like.

The mental model

A Promise has exactly two ways to finish: it resolves with a value or it rejects with a reason. Map those onto state. The request starts in a loading state. When the Promise resolves, you move to a data state — store the value, stop loading. When it rejects, you move to an error state — store the reason, stop loading. The hook holds all three pieces in useState and starts the request inside a useEffect, because kicking off a network call is a side effect that should run after render, not during it.

A first attempt

The obvious version starts the request in an effect and pipes the result straight into state:

const { useState, useEffect } = require('react');

function useQuery(queryFn) {
  const [data, setData] = useState(undefined);
  const [error, setError] = useState(undefined);
  const [isLoading, setIsLoading] = useState(true);

  useEffect(() => {
    queryFn().then((result) => {
      setData(result);
      setIsLoading(false);
    });
  }, [queryFn]);

  return { data, error, isLoading };
}

This handles the happy path and nothing else. There is no .catch, so a rejected Promise is never observed: error stays undefined, isLoading stays true, and the component is wedged on the spinner forever while a real failure goes unreported (often surfacing as an unhandled-rejection warning instead). It also never accounts for a request being superseded or the component unmounting before the Promise settles — a late result will try to set state on a component that's gone.

The working solution

const { useState, useEffect } = require('react');

function useQuery(queryFn) {
  const [data, setData] = useState(undefined);
  const [error, setError] = useState(undefined);
  const [isLoading, setIsLoading] = useState(true);

  useEffect(() => {
    // `ignore` belongs to THIS run of the effect. Its cleanup flips it to
    // true, so a promise from a superseded or unmounted run sees its own
    // closed-over flag as true and writes nothing.
    let ignore = false;

    // Reset to a clean loading state every time the query (re)starts.
    setIsLoading(true);
    setData(undefined);
    setError(undefined);

    queryFn()
      .then((result) => {
        if (ignore) return; // a newer run (or unmount) has taken over
        setData(result);
        setIsLoading(false);
      })
      .catch((err) => {
        if (ignore) return;
        setError(err); // the missing half of the naive version
        setIsLoading(false);
      });

    return () => {
      ignore = true;
    };
  }, [queryFn]); // re-run whenever the caller hands us a new queryFn

  return { data, error, isLoading };
}

module.exports = { useQuery };

Two things change from the naive version. First, the .catch closes the loop: a rejected Promise now lands in the error state instead of vanishing. Second, the ignore flag — read at the top of both handlers and set in the effect's cleanup — makes every settled Promise check whether its run is still the current one before touching state. Because each effect run gets its own ignore variable in its own closure, an old promise can never write over a newer one's results, and a promise that settles after unmount quietly does nothing.

Walking through one call

Say a component renders with queryFn A, then re-renders with a new queryFn B before A finishes:

1. Mount with A. State is { data: undefined, error: undefined, isLoading: true }. The effect runs: ignore is false, it resets the loading state and calls A(), which returns a pending Promise.
2. Re-render with B. Because queryFn changed, React runs the effect's cleanup first — setting run 1's ignore = true — then runs the effect again with a fresh ignore = false and calls B().
3. A resolves late. Its .then checks ignore, which (in A's closure) is now true, so it returns immediately and sets no state. The stale result is dropped.
4. B resolves. Its .then sees ignore still false, so it sets data to B's result and flips isLoading to false.

The component ends on B's data, never flickering to A's. The same cleanup protects against unmount: if the component is gone when A resolves, ignore is true and nothing is written, so React never warns about a state update on an unmounted component.

Gotchas

• No .catch at all. With only .then, a rejected Promise never sets error and isLoading is stuck true — the user stares at a spinner while the request has actually failed. Fix: add a .catch that sets error and clears isLoading.
• Setting state after unmount. Without a guard, a Promise that settles after the component unmounts calls a setter on a dead component, producing a React warning (and, historically, a leak). Fix: an ignore flag set in the effect cleanup, checked before every setter.
• Letting a stale request win. If queryFn changes mid-flight and you don't guard, whichever Promise resolves last wins — which might be the old one, showing stale data. Fix: the same per-run ignore flag, since cleanup runs before the next effect starts.
• Treating a falsy resolve as "still loading." Checking if (data) setIsLoading(false) breaks when the query resolves with 0, '', or null. Fix: flip isLoading in the .then itself, regardless of the value's truthiness.

Going further

• Refetch and manual triggers. Return a refetch function that re-runs queryFn on demand, so a "retry" button or a polling interval can restart the request without changing the function reference.
• AbortController. For real network calls, create an AbortController in the effect, pass its signal to fetch, and call abort() in the cleanup. That cancels the in-flight request instead of merely ignoring its result.
• Caching by key. Production data libraries (React Query, SWR) key each query by an id and share results across components, so two components asking for the same data trigger one request. The { data, error, isLoading } shape here is the same foundation they build on.