?? Defaults Overwrite Fields the Form Never Sent

The short version

Build the object you pass to Supabase’s .update() as formData.get(...) ?? default and, when that field is unsent, it is overwritten with the default every time rather than keeping its existing value. ?? conflates “there is no value” with “the field was not touched”, while the DB’s update() writes whatever key it is given — an implementation that does not separate the two will always go wrong on an edit form.

The fix is to include the key in the object only when there is a value.

What it looks like

Saving from the admin ad-slot edit form, slots already at 「掲載中」 (running) or 「申込済」 (booked) quietly rolled back to 「空き」 (vacant), simply because the form did not include availability.

No error appears. The save itself succeeds and the other fields (label, description and so on) update correctly. Only availability rolls back, and it happens on every single save.

Why

After reading the form’s inputs, updatePlacement passed them to .update() like this.

function val(raw: FormDataEntryValue | null): string | null {
  const s = String(raw ?? "").trim();
  return s || null;
}

await supabase
  .from("placements")
  .update({
    slot_seconds: f.slot_seconds,
    // Availability only reflects a manual override from the edit form. status (retired)
    // is untouched = preserve the existing value.
    availability: val(formData.get("availability")) ?? "空き",
    label: f.label,
    // ...
  })
  .eq("id", id);

The comment says “preserve the existing value” and the implementation does the opposite. val() is a helper that trims a string and returns null if it is empty. Whether the field is unsent, or present with an empty value, the result of formData.get("availability") through it is the same null. ?? "空き" replaces that null with the default the moment it sees it, so the availability key always holds some string and .update() writes it straight to the DB.

placements.availability is a column taking one of five values — 空き / 商談中 / 申込済 / 掲載中 / 終了 (vacant / in negotiation / booked / running / ended) — bound by a CHECK constraint.

add column if not exists availability      text not null default '空き'
  check (availability in ('空き','商談中','申込済','掲載中','終了')),

Which is to say this form had no way to express the intent “do not touch availability”, and wrote “空き” even on saves that meant to leave it alone. Save from a screen whose edit form has no availability input, or from a screen where that input is conditionally shown in future, and a value like 掲載中 goes back to 空き every time, no questions asked.

Fixing it

We take the value into a variable once and vary the presence of the key itself on the object passed to .update().

const availabilityOverride = val(formData.get("availability"));
const supabase = await createSupabaseServerClient();
await supabase
  .from("placements")
  .update({
    slot_seconds: f.slot_seconds,
    ...(availabilityOverride ? { availability: availabilityOverride } : {}),
    label: f.label,
    // ...
  })
  .eq("id", id);

When availabilityOverride is null (unsent or empty), the spread ...(availabilityOverride ? {...} : {}) expands to an empty object and the availability key itself is not in the payload passed to .update(). Supabase’s .update() updates only the keys it is given, so with no key that column is never touched and the DB’s existing value stays.

The point is the move from “fill in a default” to “omit the key”. ?? default is a way of deciding a value’s contents; it does not decide whether that field is updated. When a partial update needs to respect whether a field is present, the branch has to be on the presence of the key, not on the value.

Preventing a repeat

The post-fix code carries that reasoning as a comment.

// Availability only reflects a manual override from the edit form. If the form does not
// have it, drop it from the payload and preserve the existing value (avoids the footgun
// of rolling back to "空き" when the field is absent). status (retired) is untouched too.
const availabilityOverride = val(formData.get("availability"));

Moving from the “assign a default value” pattern to the “branch on the presence of the key” pattern is so that when readSlotFields’s conditionals change and more forms omit availability, the same code no longer produces the same accident. Writing it so that what gets decided each time is whether the field goes in the payload, rather than how to fill in its contents, keeps breakage from a change in form composition inside the range that compilation or review can catch.