Reaktyviosios `experimental_useFormStatus` formų validavimo valdymas

Formos yra žiniatinklio sąveikos pagrindas. Nuo paprastos naujienlaiškio registracijos iki sudėtingos daugiapakopės finansinės programos, jos yra pagrindinis kanalas, kuriuo vartotojai bendrauja su mūsų programomis. Tačiau daugelį metų formų būsenos valdymas „React“ buvo sudėtingumo, papildomo kodo ir priklausomybės nuovargio šaltinis. Mes derinomės su kontroliuojamais komponentais, kovojome su būsenos valdymo bibliotekomis ir rašėme daugybę `onChange` tvarkytuvų, visko siekdami vientisos ir intuityvios vartotojo patirties.

„React“ komanda permąstė šį pagrindinį žiniatinklio kūrimo aspektą, todėl buvo pristatyta nauja, galinga paradigma, orientuota į „React“ serverio veiksmus. Šis naujas modelis, grindžiamas progresyvaus tobulinimo principais, siekia supaprastinti formų tvarkymą perkeliant logiką arčiau jos vietos – dažnai, serverio. Šios klientinės revoliucijos pagrindą sudaro du nauji eksperimentiniai kabliai: `useFormState` ir mūsų šiandieninio aptarimo žvaigždė `experimental_useFormStatus`.

Ši išsami vadova nuodugniai panagrinės `experimental_useFormStatus` kablį. Mes ne tik nagrinėsime jo sintaksę; bet ir išnagrinėsime jo leidžiamą mąstymo modelį: būsenos pagrįstą validavimo logiką. Sužinosite, kaip šis kabliukas atskiria vartotojo sąsają nuo formos būsenos, supaprastina laukimo būsenų valdymą ir veikia kartu su serverio veiksmais, kad sukurtumėte tvirtas, prieinamas ir labai našias formas, kurios veikia net prieš įkeliant „JavaScript“. Pasiruoškite permąstyti viską, ką manėte žinąs apie formų kūrimą „React“.

Paradigmų Kaita: „React“ formų evoliucija

Kad galėtumei visiškai įvertinti `useFormStatus` atneštą inovaciją, pirmiausia turime suprasti formų valdymo kelionę „React“ ekosistemoje. Šis kontekstas pabrėžia problemas, kurias šis naujas požiūris elegantiškai sprendžia.

Senoji Gvardija: kontroliuojami komponentai ir trečiųjų šalių bibliotekos

Daugelį metų standartinis formų „React“ metodas buvo kontroliuojamų komponentų modelis. Tai apima:

• Naudojant „React“ būsenos kintamąjį (pvz., iš `useState`) kiekvienos formos įvesties reikšmei saugoti.
• Rašant `onChange` tvarkytuvą, kad būsena būtų atnaujinama kiekvienu klavišo paspaudimu.
• Perduodant būsenos kintamąjį atgal į įvesties `value` atributą.

Nors tai suteikia „React“ visišką kontrolę prie formos būseną, tai sukuria reikšmingą papildomą kodą. Dešimties laukelių formoje gali prireikti dešimties būsenos kintamųjų ir dešimties tvarkytuvų funkcijų. Validavimo, klaidų būsenų ir pateikimo būsenos valdymas prideda dar daugiau sudėtingumo, dažnai priverčiant kūrėjus kurti sudėtingus pasirinktinius kablius arba naudoti išsamias trečiųjų šalių bibliotekas.

Tokios bibliotekos kaip Formik ir React Hook Form išpopuliarėjo abstrahuodamos šį sudėtingumą. Jos teikia puikius sprendimus būsenos valdymui, validavimui ir našumo optimizavimui. Tačiau jos sudaro dar vieną valdomą priklausomybę ir dažnai veikia tik kliento pusėje, o tai gali lemti dubliuojamą validavimo logiką tarp „frontend“ ir „backend“.

Naujoji Era: Progresyvus tobulinimas ir serverio veiksmai

„React“ serverio veiksmai suteikia paradigmos pokytį. Pagrindinė idėja yra remtis žiniatinklio platformos pagrindu: standartiniu HTML `

` elementu. Forma su serverio veiksmu veikia kaip klasikinis HTML formos pateikimas – ji gali puikiai veikti net jei „JavaScript“ nepavyksta arba yra išjungtas. Tai yra progresyvaus tobulinimo esmė.

Kai „JavaScript“ įkeliama, „React“ perima formos pateikimo procesą, užkirsdama kelią visam puslapio perkrovimui ir asinhroniškai vykdydama serverio veiksmą. Tai suteikia mums geriausią iš abiejų pasaulių: serverio atvaizduojamų programų atsparumą ir vieno puslapio programos (SPA) turtingą, interaktyvią patirtį.

Šis modelis perkelia verslo logikos ir validavimo tiesos šaltinį atgal į serverį (arba į serverį panašią aplinką). Klientinės pusės kodas tampa paprastesnis, daugiausia dėmesio skiriant vartotojo sąsajos atvaizdavimui pagal tos serverio komunikacijos *būseną*. Būtent čia ir įeina `useFormStatus`.

Po gaubtu: Kas yra `experimental_useFormStatus`?

`experimental_useFormStatus` kabliukas yra kliento pusės įrankis, sukurtas teikti informaciją apie paskutinį viršutinio `` elemento pateikimą. Tai tik skaitymo kabliukas, suteikiantis komponentui viską, ką jam reikia žinoti apie formos pateikimo būseną, nereikalaujant jokių perduodamų atributų.

Pagrindinė funkcionalumas

Įsivaizduokite pateikimo mygtuką didelėje formoje. Kaip šis mygtukas žino, kada forma yra pateikiama? Tradiciškai reikėtų perduoti būsenos kintamąjį, pvz., `isSubmitting`, per kelis komponentų sluoksnius (prop drilling). Su `useFormStatus`, pateikimo mygtuko komponentas gali pats tai sužinoti.

Kabliukas turi būti iškviestas iš komponento, kuris yra atvaizduojamas *viduje* `` elemento. Tada jis teikia būsenos informaciją apie tos konkrečios formos gyvavimo ciklą.

`useFormStatus` kablio anatomija

Kai iškviečiate `const status = useFormStatus()`, gausite objektą su šiais pagrindiniais ypatumais:

• `pending` (boolean): Tai dažniausiai naudojamas ypatumas. Jis yra `true`, jei viršutinė forma šiuo metu yra pateikiama, ir `false` kitu atveju. Tai puikiai tinka mygtukams išjungti, įkėlimo indikatoriams rodyti arba laukimo būsenoms stilizuoti.
• `data` (FormData): Objektas, įgyvendinantis `FormData` sąsają. Jame yra duomenys, kurie buvo pateikti su forma. Tai nepaprastai naudinga norint įgyvendinti optimistinį vartotojo sąsajos atnaujinimą – pavyzdžiui, nedelsiant parodyti vartotojo komentarą sąraše po jo pateikimo, net nepatvirtinus jo sukūrimo serverio.
• `method` (string): HTTP metodas ('get' arba 'post'), naudojamas formos pateikimui.
• `action` (function): Nuoroda į serverio veiksmo funkciją, kuri buvo iškviesta pateikimo metu.

Auksinė Taisyklė: `` vaikas

Svarbi taisyklė, kurią reikia atsiminti, yra ta, kad komponentas, naudojantis `useFormStatus`, turi būti atvaizduojamas kaip stebimos `` elemento vaikas. Jis negali būti tame pačiame komponente, kuris pats atvaizduoja `` žymę, nes jam reikia prieiti prie formos konteksto. Štai kodėl beveik visada matysite atskirai sukurtus komponentus, tokius kaip ``, kuriuose bus `useFormStatus` logika.

Paprastas Pavyzdys: protingas pateikimo mygtukas

Pamatysime dažniausią panaudojimo atvejį veikiantį. Vietoj standartinio ``, sukursime komponentą, kuris žino apie formos pateikimo būseną.

Failas: SubmitButton.js

import { experimental_useFormStatus as useFormStatus } from 'react-dom'; export function SubmitButton() { const { pending } = useFormStatus(); return (

{pending ? 'Pateikiama...' : 'Registruotis'} ); }

Failas: SignUpForm.js

import { SubmitButton } from './SubmitButton'; import { signUpAction } from './actions'; // Serverio veiksmas export function SignUpForm() { return ( El. paštas:
); }

Šiame pavyzdyje `SubmitButton` yra visiškai savarankiškas. Jis negauna jokių atributų. Jis naudoja `useFormStatus`, kad žinotų, kada `SignUpForm` yra laukiamas, ir automatiškai išjungia save bei pakeičia tekstą. Tai galingas modelis, skirtas atskirti ir kurti daugkartinio naudojimo, formą suprantančius komponentus.

Reikalo esmė: Būsenos pagrįsta validavimo logika

Dabar pereiname prie pagrindinės koncepcijos. `useFormStatus` yra ne tik laukimo būsenoms; tai yra pagrindinis skirtingo mąstymo apie validavimą leidėjas.

„Būsenos validavimo“ apibrėžimas

Būsenos pagrįstas validavimas yra modelis, kuriame validavimo atsiliepimai daugiausia teikiami vartotojui reaguojant į formos pateikimo bandymą. Vietoj to, kad būtų validuojama kiekvieno klavišo paspaudimo metu (`onChange`) arba kai vartotojas palieka laukelį (`onBlur`), pagrindinė validavimo logika vykdoma, kai vartotojas pateikia formą. Šio pateikimo rezultatas – jo *būsena* (pvz., sėkmė, validavimo klaida, serverio klaida) – tada naudojamas vartotojo sąsajai atnaujinti.

Šis požiūris puikiai dera su „React“ serverio veiksmais. Serverio veiksmas tampa vieninteliu validavimo tiesos šaltiniu. Jis gauna formos duomenis, juos validuoja pagal jūsų verslo taisykles (pvz., „ar šis el. paštas jau naudojamas?“) ir grąžina struktūrizuotą būsenos objektą, nurodantį rezultatą.

Jo partnerio vaidmuo: `experimental_useFormState`

`useFormStatus` mums sako, *kas* vyksta (laukia), bet nepasako, *kas* įvyko. Tam mums reikia jo brolio kablio: `experimental_useFormState`.

`useFormState` yra kabliukas, skirtas atnaujinti būseną pagal formos veiksmo rezultatą. Jis priima veiksmą funkciją ir pradinę būseną kaip argumentus ir grąžina naują būseną ir apvyniotą veiksmo funkciją, kurią reikia perduoti jūsų formai.

const [state, formAction] = useFormState(myAction, initialState);

• `state`: Čia bus laikoma `myAction` paskutinio vykdymo grąžinama reikšmė. Čia gausime klaidų pranešimus.
• `formAction`: Tai yra nauja jūsų veiksmo versija, kurią turėtumėte perduoti `
  ` atributui `action`. Kai jis bus iškviestas, jis suaktyvins originalų veiksmą ir atnaujins `state`.

Kombinuotas Darbo Eiga: Nuo Spustelėjimo iki Atsiliepimo

Štai kaip `useFormState` ir `useFormStatus` veikia kartu, kad sukurtų visą validavimo ciklą:

1. Pradinis atvaizdavimas: Forma atvaizduojama su pradine būsena, kurią suteikia `useFormState`. Klaidos nerodomos.
2. Vartotojo pateikimas: Vartotojas spusteli pateikimo mygtuką.
3. Laukimo būsena: `useFormStatus` kabliukas pateikimo mygtuke nedelsiant praneša `pending: true`. Mygtukas išjungiamas ir rodomas įkėlimo pranešimas.
4. Veiksmo vykdymas: Serverio veiksmas (apvyniotas `useFormState`) vykdomas su formos duomenimis. Jis atlieka validavimą.
5. Veiksmas grįžta: Veiksmas nepavyksta validuoti ir grąžina būsenos objektą, pvz.:
   `{ message: "Validavimas nepavyko", errors: { email: "Šis el. paštas jau užimtas." } }`
6. Būsenos atnaujinimas: `useFormState` gauna šią grąžintą reikšmę ir atnaujina savo `state` kintamąjį. Tai sukelia formos komponento persikėlimą.
7. UI atsiliepimas: Forma persikeliama. `useFormStatus` `pending` būsena tampa `false`. Komponentas dabar gali perskaityti `state.errors.email` ir rodyti klaidų pranešimą šalia el. pašto įvesties laukelio.

Visas šis procesas suteikia aiškų, serverio autoritetingą atsiliepimą vartotojui, varomą vien tik pateikimo būsenos ir rezultato.

Praktinė meistriškumo klasė: daugelio laukelių registracijos formos kūrimas

Sutvirtinkime šias koncepcijas sukurdami pilną, gamyklinio stiliaus registracijos formą. Naudosime serverio veiksmą validavimui ir tiek `useFormState`, tiek `useFormStatus`, kad sukurtume puikią vartotojo patirtį.

1 Žingsnis: Serverio veiksmo su validavimu apibrėžimas

Pirmiausia mums reikia serverio veiksmo. Tvirtam validavimui naudosime populiarią biblioteką Zod. Šis veiksmas bus atskirame faile, pažymėtas `'use server';` direktyva, jei naudojate tokį karkasą kaip Next.js.

Failas: actions/authActions.js

'use server'; import { z } from 'zod'; // Nustatykite validavimo schemą const registerSchema = z.object({ username: z.string().min(3, 'Vartotojo vardas turi būti bent 3 simbolių ilgio.'), email: z.string().email('Įveskite teisingą el. pašto adresą.'), password: z.string().min(8, 'Slaptažodis turi būti bent 8 simbolių ilgio.'), }); // Nustatykite pradinę mūsų formos būseną export const initialState = { message: '', errors: {}, }; export async function registerUser(prevState, formData) { // 1. Validuokite formos duomenis const validatedFields = registerSchema.safeParse( Object.fromEntries(formData.entries()) ); // 2. Jei validavimas nepavyksta, grąžinkite klaidas if (!validatedFields.success) { return { message: 'Validavimas nepavyko. Patikrinkite laukelius.', errors: validatedFields.error.flatten().fieldErrors, }; } // 3. (Simuliacija) Patikrinkite, ar vartotojas jau egzistuoja duomenų bazėje // Reale programoje čia būtų užklausa jūsų duomenų bazėje. if (validatedFields.data.email === 'user@example.com') { return { message: 'Registracija nepavyko.', errors: { email: ['Šis el. paštas jau užregistruotas.'] }, }; } // 4. (Simuliacija) Sukurkite vartotoją console.log('Kuriant vartotoją:', validatedFields.data); // 5. Grąžinkite sėkmės būseną // Reale programoje čia galėtumėte persikreipimus naudodami `redirect()` iš 'next/navigation' return { message: 'Vartotojas sėkmingai užregistruotas!', errors: {}, }; }

Šis serverio veiksmas yra mūsų formos smegenys. Jis yra savarankiškas, saugus ir teikia aiškų duomenų struktūrą tiek sėkmės, tiek klaidų būsenoms.

2 Žingsnis: Daugkartinio naudojimo, būseną suprantančių komponentų kūrimas

Kad mūsų pagrindinis formos komponentas būtų švarus, sukursime specialius komponentus mūsų įvestims ir pateikimo mygtukui.

Failas: components/SubmitButton.js

'use client'; import { experimental_useFormStatus as useFormStatus } from 'react-dom'; export function SubmitButton({ label }) { const { pending } = useFormStatus(); return ( {pending ? 'Apdorojama...' : label} ); }

Atkreipkite dėmesį į `aria-disabled={pending}` naudojimą. Tai yra svarbi prieinamumo praktika, užtikrinanti, kad ekrano skaitytuvai teisingai paskelbtų išjungtą būseną.

3 Žingsnis: Pagrindinės formos surinkimas su `useFormState`

Dabar sujungime viską mūsų pagrindiniame formos komponente. Naudosime `useFormState`, kad susietume savo vartotojo sąsają su `registerUser` veiksmu.

Failas: components/RegistrationForm.js

'use client'; import { experimental_useFormState as useFormState } from 'react-dom'; import { registerUser, initialState } from '../actions/authActions'; import { SubmitButton } from './SubmitButton'; export function RegistrationForm() { const [state, formAction] = useFormState(registerUser, initialState); return (

Registruotis

{state?.message && !state.errors &&

{state.message}

} {state?.message && state.errors &&

{state.message}

}

Vartotojo vardas {state?.errors?.username && (

{state.errors.username[0]}

)}

El. paštas {state?.errors?.email && (

{state.errors.email[0]}

)}

Slaptažodis {state?.errors?.password && (

{state.errors.password[0]}

)}

); }

Šis komponentas dabar yra deklaratyvus ir švarus. Jis pats nevaldo jokios būsenos, išskyrus `state` objektą, kurį suteikia `useFormState`. Jo vienintelė užduotis yra atvaizduoti vartotojo sąsają pagal tą būseną. Mygtuko išjungimo logika yra įkapsuliuota `SubmitButton`, o visa validavimo logika yra `authActions.js`. Šis atsakomybių atskyrimas yra didžiulis privalumas palaikymui.

Išplėstiniai metodai ir profesionalios geriausios praktikos

Nors pagrindinis modelis yra galingas, realaus pasaulio programos dažnai reikalauja daugiau niuansų. Išnagrinėkime keletą išplėstinių metodų.

Hibridinis Požiūris: Greito ir Po pateikimo Validavimo sujungimas

Būsenos pagrįstas validavimas puikiai tinka serverio pusės patikrinimams, tačiau laukimas tinklo kelionės, kad pasakytumėte vartotojui, jog jo el. paštas neteisingas, gali būti lėtas. Hibridinis požiūris dažnai yra geriausias:

• Naudokite HTML5 Validavimą: Nepamirškite pagrindų! Atributai, pvz., `required`, `type="email"`, `minLength`, ir `pattern` suteikia momentinį, naršyklės natūralų atsiliepimą be jokio papildomo krūvio.
• Lengvas Kliento Pusės Validavimas: Grynai kosmetiniams ar formatavimo patikrinimams (pvz., slaptažodžio stiprumo indikatorius), vis tiek galite naudoti minimalų `useState` ir `onChange` tvarkytuvų kiekį.
• Serverio Pusės Autoritetas: Serverio veiksmą pasilikite kritiškiausiam, verslo logikos validavimui, kurio negalima atlikti kliento pusėje (pvz., tikrinant unikalius vartotojo vardus, validuojant pagal duomenų bazės įrašus).

Tai suteikia jums geriausią iš abiejų pasaulių: momentinį atsiliepimą dėl paprastų klaidų ir autoritetingą validavimą dėl sudėtingų taisyklių.

Prieinamumas (A11y): Formų kūrimas visiems

Prieinamumas yra neginčijamas. Įgyvendindami būsenos pagrįstą validavimą, atsiminkite šiuos dalykus:

• Klaidų paskelbimas: Mūsų pavyzdyje naudojome `aria-live="polite"` ant klaidų pranešimų konteinerių. Tai nurodo ekrano skaitytuvams paskelbti klaidos pranešimą iškart, kai jis pasirodo, nepertraukiant vartotojo dabartinio srauto.
• Klaidų susiejimas su įvestimis: Tvirtesniam ryšiui naudokite `aria-describedby` atributą. Įvestis gali nurodyti savo klaidos pranešimo konteinerio ID, sukurdama programinį ryšį.
• Fokusų valdymas: Po pateikimo su klaidomis, apsvarstykite programinį fokusą perkelkimą į pirmąjį neteisingą laukelį. Tai taupo vartotojus nuo ieškojimo, kas nepavyko.

Optimizmo UI su `useFormStatus` `data` ypatumu

Įsivaizduokite socialinės medijos programėlę, kurioje vartotojas skelbia komentarą. Vietoj to, kad rodytumėte indikatorių sekundei, galite padaryti programą jaustis akimirksniu. `useFormStatus` `data` ypatumas puikiai tinka šiam.

Kai forma pateikiama, `pending` tampa true ir `data` užpildoma pateikimo `FormData`. Jūs galite nedelsiant atvaizduoti naują komentarą laikinoje, „laukiama“ vizualinėje būsenoje naudodami šį `data`. Jei serverio veiksmas sėkmingas, pakeisite laukiamą komentarą serverio duomenimis. Jei nepavyks, galite pašalinti laukiamą komentarą ir parodyti klaidą. Tai daro programą itin jautrią.

Navigavimas „Eksperimentinėmis“ Vandomis

Svarbu nagrinėti „eksperimentinį“ prefiksą `experimental_useFormStatus` ir `experimental_useFormState`.

Ką reiškia „Eksperimentinis“

Kai „React“ žymi API kaip eksperimentinę, tai reiškia:

• API gali keistis: Pavadinimas, argumentai ar grąžinamosios reikšmės gali būti pakeistos vėlesniuose „React“ leidimuose, nesilaikant standartinio semantinio versijavimo (SemVer) dėl pertraukiančių pokyčių.
• Gali būti klaidų: Kaip nauja funkcija, ji gali turėti kraštutinių atvejų, kurie dar nėra visiškai suprasti ar išspręsti.
• Dokumentacija gali būti nepakankama: Nors pagrindinės koncepcijos yra dokumentuotos, išsamios vadovai apie išplėstinius modelius vis dar gali vystytis.

Kada priimti ir kada laukti

Taigi, ar turėtumėte naudoti savo projekte? Atsakymas priklauso nuo jūsų konteksto:

• Tinka: Asmeniniams projektams, vidiniams įrankiams, startuoliams arba komandoms, kurios yra patogios valdydamos galimus API pokyčius. Naudojant jį tokioje sistemoje kaip Next.js (kuri integruoja šias funkcijas į savo App Router) paprastai yra saugesnis variantas, nes sistema gali padėti abstrahuoti dalį kaitos.
• Naudoti atsargiai: Didelio masto įmonių programoms, kritinėms misijos sistemoms arba projektams su ilgalaikėmis priežiūros sutartimis, kur API stabilumas yra svarbiausias. Šiais atvejais gali būti protinga palaukti, kol kabliai bus paaukštinti iki stabilios API.

Visada atidžiai stebėkite oficialų „React“ tinklaraštį ir dokumentaciją dėl pranešimų, susijusių su šių kablių stabilizavimu.

Išvada: „React“ formų ateitis

`experimental_useFormStatus` ir susijusių API įvedimas yra daugiau nei tik naujas įrankis; tai reiškia filosofinį poslinkį, kaip kuriame interaktyvias patirtis su „React“. Pasinaudodami žiniatinklio platformos pagrindais ir suderindami būsenos logiką serveryje, galime kurti programas, kurios yra paprastesnės, atsparesnės ir dažnai našesnės.

Matėme, kaip `useFormStatus` suteikia švarų, atskirtą būdą komponentams reaguoti į formos pateikimo gyvavimo ciklą. Jis pašalina prop drilling laukimo būsenoms ir leidžia elegantiškus, savarankiškus UI komponentus, tokius kaip protingas `SubmitButton`. Kai kartu su `useFormState`, jis leidžia galingą būsenos pagrįsto validavimo modelį, kuriame serveris yra galutinis autoritetas, o kliento pagrindinė atsakomybė yra atvaizduoti serverio veiksmo grąžintą būseną.

Nors „eksperimentinis“ žyma reikalauja tam tikro atsargumo, kryptis yra aiški. „React“ formų ateitis yra susijusi su progresyviu tobulinimu, supaprastintu būsenos valdymu ir galinga, vientisa kliento bei serverio logikos integracija. Įvaldydami šiuos naujus kablius šiandien, jūs ne tik mokotės naują API; jūs ruošiatės kitos kartos žiniatinklio programų kūrimui su „React“.