Building the Add-Item Flow

Food Tracker (FastAPI)

Chapter 5 · Building the Add-Item Flow

Chapter 4's scan flow hands off a lookup result — or nothing at all, if the scan misses or the product isn't found. This chapter is where that result, or a manually typed one, actually becomes a row in the database.

A Trivially Short Route

# routers/items.py
@router.post("/", response_model=schemas.ItemResponse, status_code=201)
def create_item(item: schemas.ItemCreate, db: Session = Depends(get_db)):
    db_item = models.Item(**item.model_dump())
    db.add(db_item)
    db.commit()
    db.refresh(db_item)
    return db_item

Why there's almost nothing left to write here

Food Tracker (React + Express)'s own POST route began with real, hand-written validation — if (!name || typeof name !== "string" || ...) — because that route's own job was both validating and saving. This route's job is only saving. By the time create_item's own body starts executing, item is already a fully validated ItemCreate instance — Chapter 2's own type declaration on the route parameter did that work before this function was ever called. item.model_dump() unpacks the already-clean fields directly into a new Item row. There's no defensive checking left to write, because there's nothing left to defend against by this point.

What Happens When Validation Fails

Submitting a request missing name never reaches the function above at all — FastAPI intercepts it and returns a structured 422 response on its own:

{
  "detail": [
    {
      "loc": ["body", "name"],
      "msg": "Field required",
      "type": "missing"
    }
  ]
}

Compare this to Food Tracker (React + Express)'s own error shape — a single, free-form string: { "error": "name is required" }. FastAPI's detail array pinpoints exactly which field failed and why, in a consistent, machine-readable structure — genuinely useful for mapping an error directly onto the specific form input that caused it, rather than displaying one generic message regardless of which field was actually wrong.

Mapping Errors to Form Fields

// static/app.js
async function submitAddItem(formData) {
  const response = await fetch("/api/items", {
    method: "POST",
    headers: { "Content-Type": "application/json" },
    body: JSON.stringify(formData),
  });

  if (response.status === 422) {
    const { detail } = await response.json();
    showFieldErrors(detail);
    return;
  }

  const item = await response.json();
  showHomeView();
}

function showFieldErrors(detail) {
  clearFieldErrors();
  for (const err of detail) {
    const fieldName = err.loc[err.loc.length - 1];  // e.g. "name"
    const el = document.querySelector(`[data-field-error="${fieldName}"]`);
    if (el) el.textContent = err.msg;
  }
}

err.loc is itself an array — ["body", "name"] — describing exactly where in the request the problem was found; taking its last element gives the specific field name, letting showFieldErrors place each message right next to the input that actually caused it.

No duplicated validation logic on either side

An HTML5 required attribute on the name input gives instant, free client-side feedback for the obvious case — genuine UX, costing nothing to add. It is not, and doesn't need to be, a hand-written copy of the server's own validation logic the way Food Tracker (React + Express)'s own client-side check was: that course's if (!name.trim()) check duplicated real logic on both ends, while this course's client-side hint and Pydantic's own server-side schema never need to be kept in sync with each other at all, since neither one is a copy of the other's actual rules.

response_model does more than shape the docs

Declaring response_model=schemas.ItemResponse means FastAPI filters the outgoing response through that schema too — even if the Item SQLAlchemy object somehow carried an extra internal attribute never meant to be exposed, only the fields actually declared on ItemResponse would ever be serialized into the response. A genuine safety property, not just documentation sugar.

Where This Course Is Headed

Expiry alerts next — a date-filtered query for items expiring soon, and a dashboard endpoint.

Hands-On Exercises

Exercise 1

Explain why create_item's own function body contains no validation checks at all, tracing exactly what already happened to the request before that function was ever called.

📄 View solution

Exercise 2

Explain the concrete advantage of FastAPI's structured detail array over Food Tracker (React + Express)'s own single error string, specifically in terms of what showFieldErrors is able to do with it.

📄 View solution

Exercise 3

Explain why this chapter says there's "no duplicated validation logic on either side," contrasting that directly with Food Tracker (React + Express)'s own client-side name check.

📄 View solution

Chapter 5 Quick Reference

The route: POST / — six lines, no validation code, because Chapter 2's ItemCreate already did that work
422 responses: a structured detail array naming exactly which field failed and why, unlike the Express sibling's single error string
showFieldErrors: maps each detail entry's loc directly onto the form field that caused it
No duplicated logic: HTML5 required is a free UX hint, not a hand-copied version of the server's own rules
response_model: also filters the outgoing response — a genuine safety property, not just documentation sugar
Next chapter: Expiry Alerts