Kryžminė validacija, ciklas ir imitacija

11 pamokoje kiekvienas laukas buvo tikrinamas atskirai. Realios formos sudėtingesnės: taisyklės priklauso viena nuo kitos, patikros trunka laiko, o pateikimas turi savo „gyvenimo ciklą".

Kryžminė validacija (cross-field). Vienos taisyklės priklauso nuo kito lauko reikšmės. Kontaktų formoje: pasirinkus „Bug report", žinutės minimumas pakyla nuo 20 iki 50 simbolių — reikalaujam daugiau detalių. Tai įmanoma, nes rules(values) gauna visas reikšmes:

if (values.subject === 'bug') {
  base.message = [required('Message'), minLength(50, 'A bug report'), maxLength(1000)];
}

Pateikimo ciklas. Kai submit eina į tinklą (tikrą ar imituotą), mygtukas negali tiesiog „stovėti":

disabled + „Sending…"  →  sėkmė (success panelė)  arba  klaida (toast)  →  atstatom mygtuką

try/catch/finally idealiai tinka: try — siųsti, catch — klaida, finally — visada atstatyti mygtuką.

Asinchroninė validacija. „Ar vardas užimtas?" — negalima atsakyti vietoje; reikia paklausti serverio. Registracijoje tai daroma per blur (o realiai — debounce'inta užklausa į /api/username-available).

Ir sąžininga pastaba — svarbi pati savaime. Ši programa neturi backend'o. Submit'as imituojamas (fakeSend, fakeRegister). Bet visa kita — validacija, įkėlimo būsena, klaidų apdorojimas — tiksliai tokia, kokią rašytum tikram endpoint'ui. Pasikeistų tik fakeSend() — vietoj setTimeout būtų fetch. Sakau tai atvirai, nes svarbu suprasti: mokaisi tikrą modelį, ne žaislą.

Ir dar: slaptažodis niekada nesaugomas. Jokiame localStorage. Slaptažodžiai gyvena serveryje, sumaišyti (hashed) — niekada naršyklėje.