Exercise 3: Why expiryDate || null Matters — Possible Solution
====================================================================

WHAT WOULD HAPPEN WITH AN EMPTY STRING INSTEAD
------------------------------
An HTML date input that's left empty holds the value "" (an empty string), not JavaScript's null or undefined. If that empty string were sent to the server as-is and inserted directly into the expiry_date column, the database would store an empty string rather than a true SQL NULL - a real, different value, not the "no date" the app actually intends.

WHY THAT DIFFERENCE ACTUALLY MATTERS
------------------------------
Chapter 2's schema and every later query built around it (Chapter 7's expiry-alert filtering, Chapter 9's used-item logic) are written expecting NULL specifically to mean "no active expiry date." An empty string is neither NULL nor a valid date - a query checking expiry_date IS NULL would not match a row that actually holds an empty string, and a query trying to compare an empty string against a date threshold could behave unpredictably rather than being cleanly excluded the way a true NULL would be.

WHY expiryDate || null FIXES THIS
------------------------------
The || null expression converts the falsy empty string into an actual null value before it's ever sent in the request body, so the server - and ultimately the database - always receives either a real date string or a genuine null, never an empty string masquerading as "no value."

WHY THIS WORKS AS AN ANSWER
------------------------------
It correctly identifies that an empty date input produces an empty string rather than null, correctly explains why later code depends specifically on a true NULL rather than an empty string, and correctly describes how the || null normalization closes that gap before the value ever leaves the client.