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

TASK
Temporarily remove the setTypeFields({}) reset from handleTypeChange,
reproduce the leftover-field bug (fill a Book's author, switch to Cd,
fill artist, submit), and confirm via a direct GET /api/items/:id that
the saved Cd document has no author field despite it being present in
the outgoing request body. Explain why.

SOLUTION

Temporarily strip the reset:

  function handleTypeChange(e) {
    setItemType(e.target.value);
    // setTypeFields({}) removed on purpose for this exercise
  }

Reproduce the bug through the real UI:

  1. Select "Book". Type "Ursula K. Le Guin" into Author.
  2. Change the dropdown to "Cd". The Author input disappears (Cd's own
     FIELD_CONFIG entries don't include it) but typeFields itself still
     holds { author: 'Ursula K. Le Guin' } in memory.
  3. Type "Kraftwerk" into the newly-shown Artist field. typeFields is
     now { author: 'Ursula K. Le Guin', artist: 'Kraftwerk' }.
  4. Submit. The outgoing request body genuinely includes both fields:

     {"itemType":"Cd","title":"...","author":"Ursula K. Le Guin",
      "artist":"Kraftwerk"}

     (confirmed directly in the browser's Network tab, or by adding a
     temporary console.log(payload) right before the fetch call)

Confirm what actually got saved:

  curl http://localhost:4000/api/items/<the-new-Cd's-real-_id>

Output:
  {"_id":"...","title":"...","itemType":"Cd","artist":"Kraftwerk",
   "createdAt":"...","updatedAt":"..."}

No author field anywhere on the stored document, even though it was
genuinely present in the request body sent a moment earlier.

WHY THIS HAPPENS
-----------------
The route handler for POST /api/items resolves MODEL_MAP.Cd from the
request's own itemType and calls Cd.create(req.body) -- the full body,
leftover author field included. Cd's discriminator schema (Chapter 2)
was registered with the same options object as every other discriminator,
which sets discriminatorKey but never sets strict: false, so Mongoose's
own default (strict: true) applies. Under strict mode, .create() only
persists fields that exist on the target schema; author isn't one of
Cd's own fields, so Mongoose drops it silently while saving artist and
every other real Cd field normally. No error is thrown and no partial
write occurs -- the document that gets saved is simply the correct Cd
shape, as if the extra field had never been sent at all.

This is the write-side mirror of Chapter 2's own read-side warn-box and
Chapter 3's .lean() finding: strict mode filters which fields a schema
will recognize in both directions, just at different points -- on write,
it decides what gets saved; on read (without .lean()), it decides what
gets exposed after loading.

WHY THIS WORKS AS AN ANSWER
----------------------------
It reproduces the exact bug scenario the chapter describes with real UI
steps and a real inspected request body, then verifies the saved result
directly against the live database rather than assuming Mongoose's
behavior, and explains the mechanism (strict mode's field-filtering on
write) by connecting it to the same default already established for
reads in Chapters 2 and 3, rather than treating it as an unrelated new
rule.