The Add-Item Form: Type-Specific Fields, Client-Side Validation

Chapter 3 finished the plumbing: a validateItem() call, then a direct Firestore write, with real Security Rules standing behind both. This chapter builds the one form that actually produces the data going into that pipeline — and finds two places where skipping a step that was purely cosmetic for the MongoDB sibling would leave this app with a genuinely broken document.

The Same Field Configuration, Reused Directly

Personal Catalogue (React, Express & MongoDB)'s own Chapter 4 built a declarative FIELD_CONFIG object, matched field-for-field against its Mongoose discriminator schemas, to drive one shared rendering loop instead of four separate forms. Nothing about that idea is MongoDB-specific — it's reused here verbatim, matched instead against this course's own Chapter 2 field list:

Shared State, Type-Specific State

title, releaseYear, and notes are the base fields every item type shares, so they get their own piece of state, kept separate from whichever type-specific fields the FIELD_CONFIG lookup happens to be rendering right now:

The type-specific inputs render the same way the MongoDB sibling's own form does — one .map() over FIELD_CONFIG[itemType], choosing a select for a field with options and a text or number input otherwise. Nothing about that rendering logic is backend-specific, so it isn't repeated here.

The Leftover-Field Bug, Reproduced — and Not Auto-Corrected

typeFields is one shared object holding whichever fields the current type happens to use, and nothing clears it when itemType itself changes. Select Book, type an author, then switch the dropdown to Cd:

1. Book is selected. typeFields becomes { author: 'Ursula K. Le Guin' }.
2. The dropdown changes to Cd. typeFields is untouched — still { author: 'Ursula K. Le Guin' }, even though no author field is rendered anymore.
3. An artist value is typed. typeFields is now { author: 'Ursula K. Le Guin', artist: 'Kraftwerk' }.
4. The form submits with itemType: 'Cd' and both fields in the outgoing document.

The MongoDB sibling's own version of this exact bug turned out to be harmless in practice — Mongoose's default strict mode silently drops any field a document's own schema doesn't declare, so the leftover author never actually reached storage. Checking the equivalent here, directly:

The Fix — Now a Correctness Fix, Not Just a UX One

The fix itself is identical to the MongoDB sibling's own one-liner:

Closing this specific gap more thoroughly — rejecting a write outright if it carries a field no valid item type actually uses — is a real option worth naming rather than building here: Firestore Security Rules support exactly that check, via request.resource.data.keys().hasOnly([...]). Chapter 3's own rules don't do this today; the one-line client-side reset below is what actually keeps this app's real data clean until that stronger rule, if it's ever added, exists as a second line of defense.

Arrays From Text, and Why Numbers Need Real Conversion Here

Comma-separated text becomes a real array immediately before the write, exactly as the MongoDB sibling's own form does it — split, trimmed, and filtered, never stored as an array in state while it's still being typed:

releaseYear and runtimeMinutes need the same real-vs-string treatment the MongoDB sibling's own form gives them — but the reason to bother is genuinely stronger here. Every DOM input produces a string regardless of its declared type, and Mongoose's own Number SchemaType casts a valid numeric string to a real number automatically on write, whether the client remembers to convert it or not. Firestore does no such thing. Whatever JavaScript type a value has when it's handed to addDoc() is exactly the type Firestore stores — a string stays a string, permanently:

Submitting the Form

Two separate catch blocks are deliberate. The first catches validateItem()'s own synchronous throw — a specific, immediate message, no network request ever sent. The second catches whatever addDoc() itself might reject, which in practice should only ever be a real Security Rules denial, since anything validateItem() would have caught already stopped the function one line earlier.

Trying It in the Browser

With the Firestore project's rules deployed from Chapter 3, mounting <AddItemForm onCreated={(item) => console.log('Created:', item)} /> is enough to test all four types end to end: select each type, fill in its own fields, and confirm the logged item — then cross-check directly in the Firebase console's own Firestore data viewer that all four documents exist in the items collection, each with genuinely different fields, and none of them carrying a stray field left over from whichever type was selected before it. Chapter 7 replaces this console log with the real catalogue list this form is actually populating.

Hands-On Exercises