Personal Catalogue: React & Firebase — Chapter 4, Exercise 3
=====================================================================

TASK
Explain why omitting the explicit Number() conversion on
runtimeMinutes would be a genuinely more serious mistake in this
course than in the MongoDB sibling, and describe a concrete, later
scenario where the resulting bug would surface.

SOLUTION

In the MongoDB sibling, runtimeMinutes is declared on the Dvd and
Bluray discriminator schemas with type Number. Mongoose's own Number
SchemaType casts a valid numeric string to a real number automatically
at write time, regardless of whether the client bothered to convert it
first — confirmed directly in that course by checking a saved
document's own typeof and finding a real number either way. Skipping
the client-side Number() call there is a harmless redundancy; the ORM
layer catches it either way.

This course has no such layer. Firestore stores exactly the JavaScript
type it's handed by the SDK call — a string sent to addDoc() is stored
as a string field, permanently, with nothing anywhere in the stack to
convert it afterward. If the explicit Number() conversion in
handleSubmit were removed, every Dvd and Bluray document created
through this form would end up with runtimeMinutes stored as a string
like "125" rather than the number 125.

The concrete scenario where this surfaces: any future feature that
filters or sorts by runtime using a Firestore range query, such as
where("runtimeMinutes", ">", 120) for a "longer than two hours" filter.
Firestore's inequality queries compare values of the same type — a
document whose runtimeMinutes is the string "125" is simply excluded
from a query filtering against the number 120, with no error raised
anywhere to explain the missing result. The bug wouldn't show up when
the item was added; it would show up later, quietly, as a real movie
that should match a filter never appearing in the results, with nothing
in the UI or the console pointing back to why.

WHY THIS WORKS AS AN ANSWER
----------------------------
It correctly identifies the real underlying reason (Mongoose's
automatic type coercion vs. Firestore's exact-type storage) rather than
a vague "Firestore is different" claim, and it names a specific,
concrete downstream failure — a range query silently excluding
correctly-typed data — instead of a generic "it might cause bugs later"
answer.