Debounced input & autosave with timers

setTimeout(fn, 1000) schedules fn to run once, later, and immediately returns a handle — a receipt. The only way to cancel that pending call is to hand the receipt back: clearTimeout(handle).

const handle = setTimeout(() => save("hello"), 1000);
clearTimeout(handle); // never runs

That's the whole idea behind a debounce: every keystroke tears up the old receipt and takes a new one. Only the keystroke that isn't followed by another one within the delay survives to actually run.

let handle;
const scheduleSave = (value) => {
  clearTimeout(handle);           // cancel the previous, still-pending save
  handle = setTimeout(() => save(value), 1000);
};

Type h, he, hel, hell, hello quickly and save is called once, with "hello" — not five times.

A rename field that saves a second after you stop typing, and immediately when you leave the field. Four moving parts: local state for what you see, a ref for the pending timer, a ref for what you last saved, and an effect whose only job is cleanup.

const EditableTitle = ({ title, onCommit }: { title: string; onCommit: (t: string) => void }) => {
  const [text, setText] = useState(title);
  const timer = useRef<ReturnType<typeof setTimeout> | undefined>(undefined);
  const lastCommitted = useRef(title);

  // One door for every save, so "did we already save this?" is asked exactly once.
  const commit = (value: string): void => {
    if (value === lastCommitted.current) return;
    lastCommitted.current = value;
    onCommit(value);
  };

  const cancelPending = (): void => {
    if (timer.current) clearTimeout(timer.current);
    timer.current = undefined;
  };

  const scheduleCommit = (value: string): void => {
    cancelPending();
    timer.current = setTimeout(() => {
      timer.current = undefined; // it fired — there is nothing left to cancel
      commit(value);
    }, 1000);
  };

  useEffect(() => () => { if (timer.current) clearTimeout(timer.current); }, []);

  return (
    <input
      value={text}
      onChange={(e) => { setText(e.target.value); scheduleCommit(e.target.value); }}
      onBlur={() => { cancelPending(); commit(text); }}
      aria-label="Collection title"
      data-test-id="collection-title"
    />
  );
};

Why each piece is the way it is:

• setText and scheduleCommit in onChange. The input must stay responsive on every keystroke (state), while the network write is deferred (timer). Two different clocks for two different jobs.
• scheduleCommit(e.target.value), not scheduleCommit(text). text is still the previous render's value inside this handler. Read the fresh value off the event.
• onBlur cancels, then commits. Leaving the field is an explicit "I'm done" — don't make the user wait out the delay. Cancel first so the pending timer can't fire a second, redundant save.
• The guard compares against lastCommitted, not title. This is the subtle one. A tempting if (text !== title) onCommit(text) on blur is wrong twice over: after the debounce has already saved, title may not have caught up (the parent persists asynchronously, or doesn't feed the value back at all) so you save the same text twice; and if the user edits, saves, then types the original title back, text === title and the real change is never saved. A ref holding what you actually committed answers the only question that matters: "is this different from what the server has?"
• Clearing timer.current when the timer fires keeps "is a save pending?" honest. A handle left behind is a stale receipt, and clearTimeout on it silently does nothing.
• The empty-dep effect returns only a cleanup. On unmount, kill a pending timer: otherwise it fires against an unmounted component and calls onCommit for a screen the user already left.

Cancel on unmount, or flush on unmount?

The version above cancels the pending save when the component unmounts — the last edits are dropped. That's the safe default for a field that also commits on blur: clicking a Close or Save button takes focus off the input first, so blur commits before the unmount. If the field can be unmounted while focused — a modal closed with Esc, a route change — you may want to flush instead.

The catch: an empty-dep cleanup closes over the first render's text and commit forever. Since React 19.2, an Effect Event is the tool for reading the latest values from an effect without making them dependencies:

// React 19.2+
const flushPending = useEffectEvent(() => {
  if (!timer.current) return; // nothing was pending — the timer already saved it
  clearTimeout(timer.current);
  timer.current = undefined;
  commit(text); // the latest text and commit, not the first render's
});

useEffect(() => () => flushPending(), []); // the cleanup runs it on unmount

The cleanup is part of the Effect, so this keeps the rule that Effect Events are called only from inside Effects (the react-hooks lint rule accepts it here, and rejects the same call from onBlur — blur keeps calling commit directly). Two details carry the weight here:

• Flush only when a save was genuinely pending. timer.current is that flag — which only works if you set it to undefined when the timer fires and when you cancel. Otherwise unmount flushes a value the debounce already wrote.
• Route the flush through the same commit (the lastCommitted dedupe from the medium example). Belt and braces: even if the "pending?" check is wrong, the value can't be sent twice.

In development, StrictMode's extra mount cycle runs this cleanup once right after mount. Nothing is pending then, so the guard makes it a no-op.