Personal Catalogue: React & Firebase — 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 directly that the saved Cd document
really does carry a stale author field this time — unlike the MongoDB
sibling's own version of the same bug. Explain why the outcome differs.

SOLUTION

Temporary change:
function handleTypeChange(e) {
  setItemType(e.target.value);
  // setTypeFields({}); — commented out on purpose
}

Reproduction:
1. Select Book, type "Ursula K. Le Guin" into Author.
2. Switch the dropdown to Cd.
3. Type "Kraftwerk" into Artist.
4. Submit.

Console output:
Created: {id: 'm4n5o6...', itemType: 'Cd', title: '...', artist: 'Kraftwerk', author: 'Ursula K. Le Guin'}

Opening this exact document in the Firebase console's data viewer
confirms it directly: the saved document really does have a real
author field sitting alongside artist, permanently, on a document
typed "Cd".

Why the outcome differs from the MongoDB sibling:
The MongoDB sibling's own version of this bug never actually reaches
storage with the leftover field intact, because Mongoose's default
strict mode checks every field against the target discriminator's own
declared schema at write time and silently drops anything that isn't
part of it — a real, automatic safety net built into the ORM layer
itself. Firestore has no schema layer to run that same check against.
A Firestore document is just whatever fields were included in the
object passed to addDoc(); there's no declared shape anywhere for
Firestore to compare it against and strip unrecognized fields from.
Neither validateItem() nor the Chapter 3 Security Rules check for
unexpected extra fields — both only confirm that the fields a type
actually requires are present — so nothing in this app's own stack
catches the leftover field. It gets stored exactly as sent.

WHY THIS WORKS AS AN ANSWER
----------------------------
It reproduces the exact scenario the chapter describes, confirms the
real, concrete outcome by checking the actual stored document rather
than assuming the fix works the same way it did for the MongoDB
sibling, and correctly locates the reason for the difference in
Mongoose's own strict-mode field-stripping behavior having no Firestore
equivalent.