Personal Catalogue: React, Express & MongoDB — Chapter 8, Exercise 2
=====================================================================

TASK
Build the naive useDuplicateCheckNaive hook (no debounce, no
staleness guard) and reproduce the race condition described in the
chapter -- with a real "Dune" book already saved, type "Dune Messiah"
and observe a false "Dune already exists" warning appearing after the
full title has been typed.

SOLUTION

function useDuplicateCheckNaive(title) {
  const [match, setMatch] = useState(null);

  useEffect(() => {
    const trimmed = title.trim();
    if (trimmed.length < 3) {
      setMatch(null);
      return;
    }
    fetch(`http://localhost:4000/api/items/search?q=${encodeURIComponent(trimmed)}`)
      .then((res) => res.json())
      .then((results) => {
        const exact = results.find((r) => r.title.toLowerCase() === trimmed.toLowerCase());
        setMatch(exact || null);
      });
  }, [title]);

  return match;
}

Wired into AddItemForm in place of the fixed hook:

  const duplicateMatch = useDuplicateCheckNaive(shared.title);

Setup: create a real Book, title "Dune", author "Frank Herbert".

Reproducing the race: type "Dune Messiah" into the title field at a
normal, continuous typing speed (not pausing between words). Since
every keystroke past 3 characters fires its own independent request,
this genuinely produces a whole series of overlapping fetch calls
("Dun", "Dune", "Dune ", "Dune M", ... "Dune Messiah"), each racing
independently against the others over the real network.

Observed (reproducible, though the exact keystroke that "wins" the
race can vary run to run since it depends on real response timing):
after the full title "Dune Messiah" has been typed and the input has
stopped changing, the duplicate warning still shows:

  You may already have this -- "Dune" is already in your catalogue.

even though the title field genuinely reads "Dune Messiah" at that
exact moment, and there is no book named "Dune Messiah" in the
catalogue at all. A later request (for a longer input string, once the
full title had actually settled) is the correct, current state; an
earlier request for a shorter, already-superseded input string happened
to resolve after it, silently overwriting the correct null result.

WHY THIS WORKS AS AN ANSWER
----------------------------
It builds the exact naive hook the chapter describes, wires it into
the real running form, and reproduces the genuine out-of-order-response
symptom with real network requests and a real, checkable false-positive
warning -- rather than only describing the theoretical possibility of
a race condition without ever actually triggering one.