Solution

You'll hold status, value, and error in state and expose a memoized execute that drives them through the async lifecycle — optionally kicked off once on mount.

The problem, in plain English

Every promise a component runs goes through the same arc: it hasn't started (idle), it's running (pending), and it either succeeded (success, with a value) or failed (error, with a reason). Components re-implement that arc constantly, usually with three useStates and a lot of copy-paste. useAsync factors it out into one hook that works for any promise-returning function, and separates "what to run" (the function) from "when to run it" (execute, or the immediate flag on mount).

The mental model

Two decisions: the state machine and the trigger. The state machine is idle → pending → success | error, and execute is what advances it — reset to pending, then land on success or error when the promise settles. The trigger is who calls execute: the immediate flag calls it once from an effect on mount; otherwise an event handler calls it. Keeping execute stable (memoized) lets it be both an effect dependency and a click handler without churning.

A first attempt

The naive version tracks a single boolean and forgets to reset between runs:

function useAsyncNaive(asyncFunction) {
  const [loading, setLoading] = useState(false);
  const [value, setValue] = useState(null);
  const [error, setError] = useState(null);

  const execute = () => {          // new identity every render
    setLoading(true);
    return asyncFunction()
      .then((v) => setValue(v))     // stale error left in place
      .catch((e) => setError(e))
      .finally(() => setLoading(false));
  };

  return { execute, loading, value, error };
}

Three problems. A boolean loading can't express idle vs success vs error — you can't tell "never ran" from "ran and succeeded". Re-running doesn't clear the previous error or value, so a retry that succeeds still shows the old error. And execute is recreated every render, so it can't safely go in an effect's dependency array (it'd re-run forever) or be compared by memoized children.

The working solution

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

function useAsync(asyncFunction, immediate = true) {
  const [status, setStatus] = useState('idle');
  const [value, setValue] = useState(null);
  const [error, setError] = useState(null);

  const execute = useCallback(
    (...args) => {
      setStatus('pending');
      setValue(null);   // clear stale results up front
      setError(null);
      return asyncFunction(...args)
        .then((response) => {
          setValue(response);
          setStatus('success');
          return response; // so callers can await the value
        })
        .catch((err) => {
          setError(err);
          setStatus('error');
        });
    },
    [asyncFunction],
  );

  useEffect(() => {
    if (immediate) execute();
  }, [execute, immediate]);

  return { execute, status, value, error };
}

module.exports = { useAsync };

A four-value status string replaces the boolean, so every stage is distinguishable. execute resets pending/value/error before awaiting, so a retry starts clean, then settles the state on resolve or reject and returns the response for callers who await execute(). It's wrapped in useCallback([asyncFunction]), giving it a stable identity as long as the passed function is stable — which is exactly what makes the mount effect safe: useEffect(() => { if (immediate) execute() }, [execute, immediate]) runs once, not every render. Separating execute from the effect is what lets the same hook serve both "load on mount" and "run on click".

Walking through one call

Use useAsync(saveDraft, false) (manual), then click Save, which rejects, then click again and it succeeds:

• mount — status is idle; immediate is false, so nothing runs. The button reads "Save".
• click 1 — execute(draft): status → 'pending', value/error cleared. Button disables to "Saving…". saveDraft rejects → catch sets error, status → 'error'. Button shows the error.
• click 2 — execute(draft): status → 'pending' again, and crucially error is cleared now, so the UI doesn't show a stale error while retrying. saveDraft resolves → value set, status → 'success'.

The reset-on-execute is what makes the retry feel correct; without it, click 2 would flash the old error until it resolved.

Gotchas

• A boolean instead of a status — can't distinguish idle/success/error. Use a 'idle' | 'pending' | 'success' | 'error' string.
• Not clearing on re-execute — a retry shows the previous value/error until it settles. Reset both when moving to pending.
• Unstable execute — recreating it every render makes the mount effect loop and breaks memoized consumers. useCallback on asyncFunction.
• Inline asyncFunction — passing a fresh function each render changes execute, re-triggering the immediate effect. Memoize it at the call site (or wrap it in useCallback).

Going further

• Cancellation — tracking a "current run" id (or an AbortController) lets a newer execute invalidate an older one's result, the same race fix useFetch needs.
• useAsyncRetry — layering a retry() that re-runs the last call on top of this hook is a small, common extension.
• Reducer form — collapsing the three useStates into one useReducer makes the transitions atomic and the state machine explicit.