Dva formuláře, dva nekompatibilní číselníky nad stejným DB sloupcem

import { Aside } from ‘@astrojs/starlight/components’;

Jeden sloupec = jeden kanonický formát hodnot definovaný na jednom místě; každý formulář, který do něj zapisuje, importuje tentýž číselník a prefill musí mít tolerantní mapování pro legacy hodnoty.

Symptom

Uživatel otevře editaci profilu, nic nezmění a uloží — formulář odmítne s „vyplňte zemi”. Země je přitom v DB vyplněná. Postiženo prakticky 100 % účtů; nikdo to roky nenahlásil, protože uživatel to obešel opětovným vybráním země (a tím si hodnotu tiše přepsal do druhého formátu).

Root cause

Dva formuláře zapisující do téhož sloupce vznikly v různou dobu s různými číselníky:

<!-- registrace (původní) -->
<option value="Česká republika">…</option>

<!-- editace profilu (přidaná později) -->
<option value="CZ">Česká republika</option>

Prefill select.value = row.country se u hodnoty "Česká republika" netrefí do žádné option s value "CZ" → select zůstane prázdný → required blokuje submit. DB tak obsahovala směs obou formátů a každé uložení profilu hodnotu „překonvertovalo” do formátu daného formuláře.

Fix

1. Zvolit kanonický formát podle většiny dat (zde plné názvy — 99 % řádků), ne podle „čistšího” formátu, pokud by vyžadoval migraci + úpravu všech čteček (faktury tiskly raw hodnotu).
2. Sjednotit option values obou formulářů na kanonický formát.
3. Tolerantní prefill pro menšinový legacy formát:

const BY_CODE = { CZ: 'Česká republika', SK: 'Slovensko', /* … */ };
select.value = BY_CODE[String(raw).toUpperCase()] || raw;

4. Tam, kde jiný formulář potřebuje druhý formát (checkout s ISO kódy kvůli dopravě), mapovat na hranici — a před přiřazením ověřit, že option existuje.

Jak se tomu vyvarovat v jiných systémech

• Detection: SQL na rozložení hodnot — SELECT col, count(*) FROM t GROUP BY 1 ORDER BY 2 DESC — směs formátů (kódy vedle názvů, různé jazyky) = tenhle bug. Frontend: grep všech <option value= nad stejným polem napříč stránkami a diff množin.
• Anti-pattern: copy-paste formuláře s vlastním inline číselníkem; required select, jehož prefill je prosté el.value = dbValue bez kontroly zásahu.
• Lepší přístup: číselník jako sdílený modul (jeden export, importují všechny formuláře i validace); prefill helper, který loguje/hlásí miss; integration test „ulož beze změny” na reálných datech (uložení profilu bez editace nesmí selhat ani změnit hodnoty).

Sister bugs / související

Stejná rodina: validační pravidla přidaná po importu legacy dat (povinná pole, která stará data nemají) — uživatel je rukojmím dat, která nevytvořil. Řešení vždy: normalizovat při čtení / blokovat jen zhoršení (clear), ne existující stav.