Personal Catalogue: React, Express & MongoDB — Chapter 7, Exercise 3
=====================================================================

TASK
Temporarily remove the onTagsChange wiring between ItemDetail and App
(pass no onChange to TagEditor at all), then edit a book's tags, go
back to the list, and reopen it -- confirm the stale-tags bug
reappears. Restore the wiring and confirm the fix.

SOLUTION

Temporarily strip the wiring in App.jsx:

  selectedItem ? (
    <ItemDetail
      item={selectedItem}
      onBack={() => setSelectedId(null)}
      // onTagsChange prop removed on purpose
    />
  ) : ( ... )

and in ItemDetail.jsx, since onTagsChange is now undefined:

  {item.itemType === 'Book' && (
    <TagEditor
      bookId={item._id}
      initialTags={item.tags || []}
      onChange={onTagsChange}   // now undefined -- TagEditor's own
                                 // onChange?.() call simply does nothing
    />
  )}

Reproduce the bug through the real UI:

  1. Open a real Book with tags: ["Programming"].
  2. Using the TagEditor, add "Software Design". The PATCH request
     succeeds -- confirmed directly with curl GET /api/items/<id>,
     which correctly shows tags: ["Programming", "Software Design"] in
     the database.
  3. Click "Back to list".
  4. Reopen the same book's detail view.

Observed: the reopened detail view shows tags: ["Programming"] only --
the newly added "Software Design" tag is missing, even though it
genuinely exists in the database and TagEditor's own internal state
correctly showed it a moment before clicking "Back to list."

WHY THIS HAPPENS
-----------------
The detail view never re-fetches from the server (per this chapter's
own "No Extra Fetch Needed" tip-box) -- it reads directly from the
shared items array held in App's own state. TagEditor's internal state
updated correctly when the tag was added, but with no onChange callback
wired up, App's own items array was never told about that change. The
very next time ItemDetail renders (after reopening from the list), it
receives initialTags from App's own stale copy of the item -- the one
still holding ["Programming"] -- and TagEditor initializes fresh from
that stale value, discarding whatever it had shown a moment earlier.

Restore the wiring:

  <ItemDetail
    item={selectedItem}
    onBack={() => setSelectedId(null)}
    onTagsChange={(tags) => handleTagsChange(selectedItem._id, tags)}
  />

Repeating the identical four steps now shows the reopened detail view
correctly displaying tags: ["Programming", "Software Design"] -- the
edit is reflected because handleTagsChange updated App's own items
array at the moment the tag was added, not only in TagEditor's own
short-lived local state.

WHY THIS WORKS AS AN ANSWER
----------------------------
It reproduces the exact stale-data bug the chapter's finding-box
describes with real UI steps and a real, verified-in-the-database tag
addition that still doesn't survive a round trip through the list, then
identifies the real cause (App's own state never being told about the
change) rather than blaming TagEditor or the backend, and confirms the
fix by repeating the identical steps and getting a correct result.