Formu validācijas meistarība ar React `experimental_useFormStatus`

Formas ir tīmekļa mijiedarbības pamats. No vienkāršas jaunumu vēstules pierakstīšanās līdz sarežģītai daudzpakāpju finanšu lietojumprogrammai, tās ir galvenais kanāls, caur kuru lietotāji sazinās ar mūsu aplikācijām. Tomēr gadiem ilgi formu stāvokļa pārvaldība React ir bijusi sarežģītības, lieka koda un atkarību noguruma avots. Mēs esam žonglējuši ar kontrolētajām komponentēm, cīnījušies ar stāvokļa pārvaldības bibliotēkām un rakstījuši neskaitāmus `onChange` apstrādātājus, viss, lai sasniegtu nevainojamu un intuitīvu lietotāja pieredzi.

React komanda ir pārdomājusi šo fundamentālo tīmekļa izstrādes aspektu, kas noveda pie jaunas, jaudīgas paradigmas ieviešanas, kuras centrā ir React Server Actions (Servera Darbības). Šis jaunais modelis, kas balstīts uz progresīvās uzlabošanas principiem, mērķē vienkāršot formu apstrādi, pārvietojot loģiku tuvāk tai vietai, kur tai jābūt — bieži vien serverim. Šīs klienta puses revolūcijas centrā ir divi jauni eksperimentāli hook: `useFormState` un mūsu šodienas diskusijas zvaigzne, `experimental_useFormStatus`.

Šī visaptverošā rokasgrāmata jūs vedīs padziļinātā `experimental_useFormStatus` hook izpētē. Mēs ne tikai aplūkosim tā sintaksi; mēs izpētīsim mentālo modeli, ko tas nodrošina: uz statusu balstītu validācijas loģiku. Jūs uzzināsiet, kā šis hook atsaista lietotāja saskarni no formas stāvokļa, vienkāršo gaidīšanas (pending) stāvokļu pārvaldību un darbojas kopā ar Servera Darbībām, lai izveidotu robustas, pieejamas un augstas veiktspējas formas, kas darbojas pat pirms JavaScript ielādes. Sagatavojieties pārdomāt visu, ko jūs domājāt zinām par formu veidošanu React.

Paradigmas maiņa: React formu evolūcija

Lai pilnībā novērtētu inovāciju, ko sniedz `useFormStatus`, mums vispirms ir jāsaprot formu pārvaldības ceļš React ekosistēmā. Šis konteksts izceļ problēmas, kuras šī jaunā pieeja eleganti atrisina.

Vecā gvarde: kontrolētās komponentes un trešo pušu bibliotēkas

Gadiem ilgi standarta pieeja formām React bija kontrolētās komponentes (controlled component) modelis. Tas ietver:

• React stāvokļa mainīgā (piem., no `useState`) izmantošana, lai glabātu katra formas ievades lauka vērtību.
• `onChange` apstrādātāja rakstīšana, lai atjauninātu stāvokli pie katra taustiņspiediena.
• Stāvokļa mainīgā padošana atpakaļ uz ievades lauka `value` prop.

Lai gan tas dod React pilnīgu kontroli pār formas stāvokli, tas rada ievērojamu daudzumu lieka koda. Formai ar desmit laukiem jums varētu būt nepieciešami desmit stāvokļa mainīgie un desmit apstrādātāja funkcijas. Validācijas, kļūdu stāvokļu un iesniegšanas statusa pārvaldība pievieno vēl vairāk sarežģītības, bieži liekot izstrādātājiem veidot sarežģītus pielāgotus hook vai ķerties pie visaptverošām trešo pušu bibliotēkām.

Bibliotēkas kā Formik un React Hook Form kļuva populāras, abstrahējot šo sarežģītību. Tās nodrošina izcilus risinājumus stāvokļa pārvaldībai, validācijai un veiktspējas optimizācijai. Tomēr tās ir vēl viena atkarība, kas jāpārvalda, un bieži darbojas pilnībā klienta pusē, kas var novest pie dublētas validācijas loģikas starp frontend un backend.

Jaunā ēra: progresīvā uzlabošana un servera darbības

React Servera Darbības (Server Actions) ievieš paradigmas maiņu. Galvenā ideja ir balstīties uz tīmekļa platformas pamatiem: standarta HTML `

` elementu. Forma ar servera darbību darbojas kā klasiska HTML formas iesniegšana — tā var perfekti funkcionēt pat tad, ja JavaScript neizdodas ielādēt vai ir atspējots. Tā ir progresīvās uzlabošanas (progressive enhancement) būtība.

Kad JavaScript ielādējas, React "pārtver" formas iesniegšanas procesu, novēršot pilnas lapas pārlādi un izpildot servera darbību asinhroni. Tas mums dod labāko no abām pasaulēm: servera renderētu aplikāciju noturību un bagātīgu, interaktīvu vienas lapas aplikācijas (SPA) pieredzi.

Šis modelis pārvieto biznesa loģikas un validācijas patiesības avotu atpakaļ uz serveri (vai serverim līdzīgu vidi). Klienta puses kods kļūst vienkāršāks, galvenokārt rūpējoties par lietotāja saskarnes renderēšanu, pamatojoties uz šīs servera komunikācijas *statusu*. Tieši šeit spēlē ienāk `useFormStatus`.

Aizkulisēs: Kas ir `experimental_useFormStatus`?

`experimental_useFormStatus` hook ir klienta puses rīks, kas paredzēts, lai sniegtu informāciju par vecāk-elementa `` pēdējo iesniegšanu. Tas ir tikai lasāms hook, kas komponentei pastāsta visu, kas tai jāzina par formas iesniegšanas statusu, bez nepieciešamības padot jebkādus prop-us.

Pamatfunkcionalitāte

Iedomājieties iesniegšanas pogu lielas formas iekšienē. Kā šī poga zina, kad forma tiek iesniegta? Tradicionāli jums būtu jāpadod stāvokļa mainīgais, piemēram, `isSubmitting`, cauri vairākiem komponenšu slāņiem (prop drilling). Ar `useFormStatus` pogas komponente var uzzināt šo informāciju pati.

Hook ir jāizsauc no komponentes, kas tiek renderēta *iekš* `` elementa. Tad tas sniedz statusa informāciju par šīs konkrētās formas dzīves ciklu.

`useFormStatus` Hook anatomija

Kad jūs izsaucat `const status = useFormStatus()`, jūs atgriezeniski saņemat objektu ar šādām galvenajām īpašībām:

• `pending` (boolean): Šī ir visbiežāk izmantotā īpašība. Tā ir `true`, ja vecāk-forma pašlaik tiek iesniegta, un `false` citādi. Tā ir ideāli piemērota pogu atspējošanai, ielādes indikatoru rādīšanai vai gaidīšanas stāvokļu stilizēšanai.
• `data` (FormData): Objekts, kas implementē `FormData` saskarni. Tas satur datus, kas tika iesniegti kopā ar formu. Tas ir neticami noderīgi, lai ieviestu optimistiskus lietotāja saskarnes atjauninājumus — piemēram, parādot lietotāja komentāru sarakstā uzreiz pēc tā iesniegšanas, pat pirms serveris ir apstiprinājis tā izveidi.
• `method` (string): HTTP metode ('get' vai 'post'), kas izmantota formas iesniegšanai.
• `action` (function): Atsauce uz servera darbības funkciju, kas tika izsaukta iesniegšanas laikā.

Zelta likums: `` bērnelements

Svarīgs noteikums, kas jāatceras, ir tas, ka komponentei, kas izmanto `useFormStatus`, jābūt renderētai kā bērnelementam `` elementam, kuru tā uzrauga. Tā nevar būt tajā pašā komponentē, kas renderē pašu `` tagu, jo tai ir nepieciešams piekļūt formas kontekstam. Tāpēc jūs gandrīz vienmēr redzēsiet, ka komponentes, piemēram, ``, tiek izveidotas atsevišķi, lai tajās ievietotu `useFormStatus` loģiku.

Vienkāršs piemērs: Viedā iesniegšanas poga

Aplūkosim visbiežāko lietošanas gadījumu darbībā. Standarta `` vietā mēs izveidosim komponenti, kas ir informēta par formas iesniegšanas stāvokli.

Fails: SubmitButton.js

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

{pending ? 'Submitting...' : 'Sign Up'} ); }

Fails: SignUpForm.js

import { SubmitButton } from './SubmitButton'; import { signUpAction } from './actions'; // A server action export function SignUpForm() { return ( Email:
); }

Šajā piemērā `SubmitButton` ir pilnīgi pašpietiekama. Tā nesaņem nekādus prop-us. Tā izmanto `useFormStatus`, lai zinātu, kad `SignUpForm` ir gaidīšanas stāvoklī, un automātiski atspējo sevi un maina savu tekstu. Šis ir spēcīgs modelis atsaistei un atkārtoti lietojamu, par formu informētu komponenšu izveidei.

Lietas būtība: uz statusu balstīta validācijas loģika

Tagad mēs esam nonākuši pie galvenā koncepta. `useFormStatus` nav domāts tikai ielādes stāvokļiem; tas ir galvenais veicinātājs citādam domāšanas veidam par validāciju.

"Statusa validācijas" definēšana

Uz statusu balstīta validācija ir modelis, kurā validācijas atgriezeniskā saite lietotājam galvenokārt tiek sniegta kā atbilde uz formas iesniegšanas mēģinājumu. Tā vietā, lai validētu pie katra taustiņspiediena (`onChange`) vai kad lietotājs pamet lauku (`onBlur`), galvenā validācijas loģika tiek izpildīta, kad lietotājs iesniedz formu. Šīs iesniegšanas rezultāts — tās *statuss* (piemēram, veiksmīgs, validācijas kļūda, servera kļūda) — tiek izmantots, lai atjauninātu lietotāja saskarni.

Šī pieeja lieliski saskan ar React Servera Darbībām. Servera darbība kļūst par vienīgo patiesības avotu validācijai. Tā saņem formas datus, validē tos atbilstoši jūsu biznesa noteikumiem (piemēram, "vai šis e-pasts jau tiek izmantots?") un atgriež strukturētu stāvokļa objektu, kas norāda rezultātu.

Tā partnera loma: `experimental_useFormState`

`useFormStatus` mums pasaka, *kas* notiek (gaidīšanas stāvoklis), bet tas mums nepasaka, kāds ir notikušā *rezultāts*. Tam mums ir nepieciešams tā radniecīgais hook: `experimental_useFormState`.

`useFormState` ir hook, kas paredzēts stāvokļa atjaunināšanai, pamatojoties uz formas darbības rezultātu. Tas kā argumentus pieņem darbības funkciju un sākotnējo stāvokli un atgriež jaunu stāvokli un ietītu darbības funkciju, ko padot jūsu formai.

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

• `state`: Tas saturēs atgriezes vērtību no pēdējās `myAction` izpildes. Šeit mēs saņemsim savus kļūdu paziņojumus.
• `formAction`: Šī ir jauna jūsu darbības versija, kas jums jāpadod `
  ` `action` prop-am. Kad tā tiks izsaukta, tā aktivizēs sākotnējo darbību un atjauninās `state`.

Apvienotā darbplūsma: no klikšķa līdz atgriezeniskajai saitei

Lūk, kā `useFormState` un `useFormStatus` strādā kopā, lai izveidotu pilnu validācijas ciklu:

1. Sākotnējā renderēšana: Forma tiek renderēta ar sākotnējo stāvokli, ko nodrošina `useFormState`. Kļūdas netiek rādītas.
2. Lietotāja iesniegšana: Lietotājs noklikšķina uz iesniegšanas pogas.
3. Gaidīšanas stāvoklis: `useFormStatus` hook iesniegšanas pogā nekavējoties ziņo `pending: true`. Poga kļūst atspējota un rāda ielādes ziņojumu.
4. Darbības izpilde: Servera darbība (ko ietin `useFormState`) tiek izpildīta ar formas datiem. Tā veic validāciju.
5. Darbība atgriež rezultātu: Darbībai neizdodas validācija, un tā atgriež stāvokļa objektu, piemēram:
   `{ message: "Validation failed", errors: { email: "This email is already taken." } }`
6. Stāvokļa atjaunināšana: `useFormState` saņem šo atgriezes vērtību un atjaunina savu `state` mainīgo. Tas izraisa formas komponentes pārrenderēšanu.
7. Lietotāja saskarnes atgriezeniskā saite: Forma tiek pārrenderēta. `pending` statuss no `useFormStatus` kļūst `false`. Komponente tagad var nolasīt `state.errors.email` un parādīt kļūdas ziņojumu blakus e-pasta ievades laukam.

Visa šī plūsma nodrošina skaidru, servera autoritatīvu atgriezenisko saiti lietotājam, ko pilnībā vada iesniegšanas statuss un rezultāts.

Praktiskā meistarklase: daudz-lauku reģistrācijas formas veidošana

Nostiprināsim šos konceptus, izveidojot pilnīgu, ražošanas stila reģistrācijas formu. Mēs izmantosim servera darbību validācijai un gan `useFormState`, gan `useFormStatus`, lai radītu lielisku lietotāja pieredzi.

1. solis: Servera darbības definēšana ar validāciju

Pirmkārt, mums ir nepieciešama mūsu servera darbība. Robustai validācijai mēs izmantosim populāro bibliotēku Zod. Šī darbība atradīsies atsevišķā failā, kas atzīmēts ar direktīvu `'use server';`, ja izmantojat ietvaru kā Next.js.

Fails: actions/authActions.js

'use server'; import { z } from 'zod'; // Definējam validācijas shēmu const registerSchema = z.object({ username: z.string().min(3, 'Lietotājvārdam jābūt vismaz 3 rakstzīmes garam.'), email: z.string().email('Lūdzu, ievadiet derīgu e-pasta adresi.'), password: z.string().min(8, 'Parolei jābūt vismaz 8 rakstzīmes garai.'), }); // Definējam sākotnējo stāvokli mūsu formai export const initialState = { message: '', errors: {}, }; export async function registerUser(prevState, formData) { // 1. Validējam formas datus const validatedFields = registerSchema.safeParse( Object.fromEntries(formData.entries()) ); // 2. Ja validācija neizdodas, atgriežam kļūdas if (!validatedFields.success) { return { message: 'Validācija neizdevās. Lūdzu, pārbaudiet laukus.', errors: validatedFields.error.flatten().fieldErrors, }; } // 3. (Simulācija) Pārbaudām, vai lietotājs jau eksistē datubāzē // Reālā aplikācijā šeit jūs veiktu vaicājumu datubāzē. if (validatedFields.data.email === 'user@example.com') { return { message: 'Reģistrācija neizdevās.', errors: { email: ['Šis e-pasts jau ir reģistrēts.'] }, }; } // 4. (Simulācija) Izveidojam lietotāju console.log('Veido lietotāju:', validatedFields.data); // 5. Atgriežam veiksmīgu stāvokli // Reālā aplikācijā šeit jūs varētu veikt pāradresāciju, izmantojot `redirect()` no 'next/navigation' return { message: 'Lietotājs veiksmīgi reģistrēts!', errors: {}, }; }

Šī servera darbība ir mūsu formas smadzenes. Tā ir pašpietiekama, droša un nodrošina skaidru datu struktūru gan veiksmes, gan kļūdu stāvokļiem.

2. solis: Atkārtoti lietojamu, par statusu informētu komponenšu veidošana

Lai mūsu galvenā formas komponente būtu tīra, mēs izveidosim īpašas komponentes mūsu ievades laukiem un iesniegšanas pogai.

Fails: components/SubmitButton.js

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

Ievērojiet `aria-disabled={pending}` izmantošanu. Tā ir svarīga pieejamības prakse, nodrošinot, ka ekrāna lasītāji pareizi paziņo par atspējoto stāvokli.

3. solis: Galvenās formas salikšana ar `useFormState`

Tagad saliksim visu kopā mūsu galvenajā formas komponentē. Mēs izmantosim `useFormState`, lai savienotu mūsu lietotāja saskarni ar `registerUser` darbību.

Fails: 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 (

Register

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

{state.message}

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

{state.message}

}

Username {state?.errors?.username && (

{state.errors.username[0]}

)}

Email {state?.errors?.email && (

{state.errors.email[0]}

)}

Password {state?.errors?.password && (

{state.errors.password[0]}

)}

); }

Šī komponente tagad ir deklaratīva un tīra. Tā pati nepārvalda nekādu stāvokli, izņemot `state` objektu, ko nodrošina `useFormState`. Tās vienīgais uzdevums ir renderēt lietotāja saskarni, pamatojoties uz šo stāvokli. Loģika pogas atspējošanai ir iekapsulēta `SubmitButton`, un visa validācijas loģika atrodas `authActions.js`. Šī pienākumu nodalīšana ir milzīgs ieguvums uzturēšanai.

Padziļinātas tehnikas un profesionālās labākās prakses

Lai gan pamata modelis ir spēcīgs, reālās pasaules aplikācijām bieži nepieciešama lielāka nianse. Apskatīsim dažas padziļinātas tehnikas.

Hibrīda pieeja: tūlītējas un pēc-iesniegšanas validācijas apvienošana

Uz statusu balstīta validācija ir lieliska servera puses pārbaudēm, bet gaidīšana uz tīkla pieprasījumu, lai pateiktu lietotājam, ka viņa e-pasts ir nederīgs, var būt lēna. Hibrīda pieeja bieži ir labākā:

• Izmantojiet HTML5 validāciju: Neaizmirstiet pamatus! Atribūti kā `required`, `type="email"`, `minLength` un `pattern` nodrošina tūlītēju, pārlūkprogrammas dabisko atgriezenisko saiti bez papildu izmaksām.
• Viegla klienta puses validācija: Tīri kosmētiskām vai formatēšanas pārbaudēm (piem., paroles stipruma indikators) joprojām varat izmantot minimālu daudzumu `useState` un `onChange` apstrādātāju.
• Servera puses autoritāte: Rezervējiet servera darbību vissvarīgākajai, biznesa loģikas validācijai, ko nevar veikt klienta pusē (piem., unikālu lietotājvārdu pārbaude, validācija pret datubāzes ierakstiem).

Tas sniedz jums labāko no abām pasaulēm: tūlītēju atgriezenisko saiti par vienkāršām kļūdām un autoritatīvu validāciju sarežģītiem noteikumiem.

Pieejamība (A11y): Formu veidošana visiem

Pieejamība nav apspriežama. Ieviešot uz statusu balstītu validāciju, paturiet prātā šos punktus:

• Paziņojiet par kļūdām: Mūsu piemērā mēs izmantojām `aria-live="polite"` uz kļūdu ziņojumu konteineriem. Tas liek ekrāna lasītājiem paziņot kļūdas ziņojumu, tiklīdz tas parādās, nepārtraucot lietotāja pašreizējo plūsmu.
• Saistiet kļūdas ar ievades laukiem: Lai izveidotu robustāku savienojumu, izmantojiet `aria-describedby` atribūtu. Ievades lauks var norādīt uz sava kļūdas ziņojuma konteinera ID, izveidojot programmatisku saiti.
• Fokusa pārvaldība: Pēc iesniegšanas ar kļūdām apsveriet iespēju programmatiski pārvietot fokusu uz pirmo nederīgo lauku. Tas ietaupa lietotājiem laiku, meklējot, kas nogāja greizi.

Optimistiskā saskarne ar `useFormStatus` `data` īpašību

Iedomājieties sociālo mediju aplikāciju, kur lietotājs publicē komentāru. Tā vietā, lai uz sekundi rādītu ielādes indikatoru, jūs varat likt aplikācijai justies tūlītējai. `data` īpašība no `useFormStatus` tam ir ideāli piemērota.

Kad forma tiek iesniegta, `pending` kļūst par `true`, un `data` tiek aizpildīts ar iesnieguma `FormData`. Jūs varat nekavējoties renderēt jauno komentāru pagaidu, 'gaidīšanas' vizuālā stāvoklī, izmantojot šos `data`. Ja servera darbība ir veiksmīga, jūs aizstājat gaidīšanas komentāru ar galīgajiem datiem no servera. Ja tā neizdodas, jūs varat noņemt gaidīšanas komentāru un parādīt kļūdu. Tas liek aplikācijai justies neticami atsaucīgai.

Navigācija "eksperimentālajos" ūdeņos

Ir svarīgi pievērsties "experimental" prefiksam `experimental_useFormStatus` un `experimental_useFormState` nosaukumos.

Ko "eksperimentāls" patiesībā nozīmē

Kad React apzīmē API kā eksperimentālu, tas nozīmē:

• API var mainīties: Nosaukums, argumenti vai atgriezes vērtības var tikt mainītas nākamajā React laidienā, neievērojot standarta semantisko versiju (SemVer) attiecībā uz "breaking changes".
• Var būt kļūdas: Kā jauna funkcija, tai var būt robežgadījumi, kas vēl nav pilnībā izprasti vai atrisināti.
• Dokumentācija var būt nepilnīga: Lai gan pamatkoncepti ir dokumentēti, detalizētas rokasgrāmatas par padziļinātiem modeļiem vēl var attīstīties.

Kad ieviest un kad gaidīt

Tātad, vai jums to vajadzētu izmantot savā projektā? Atbilde ir atkarīga no jūsu konteksta:

• Piemērots: Personīgajiem projektiem, iekšējiem rīkiem, jaunuzņēmumiem vai komandām, kuras ir gatavas pārvaldīt potenciālās API izmaiņas. To izmantošana ietvarā, piemēram, Next.js (kas šīs funkcijas ir integrējis savā App Router), parasti ir drošāka izvēle, jo ietvars var palīdzēt abstrahēt daļu no izmaiņām.
• Lietot ar piesardzību: Liela mēroga uzņēmumu aplikācijām, misijai kritiski svarīgām sistēmām vai projektiem ar ilgtermiņa uzturēšanas līgumiem, kur API stabilitāte ir vissvarīgākā. Šādos gadījumos varētu būt prātīgi pagaidīt, līdz hook tiek paaugstināti uz stabilu API.

Vienmēr sekojiet līdzi oficiālajam React blogam un dokumentācijai, lai uzzinātu par paziņojumiem saistībā ar šo hook stabilizāciju.

Noslēgums: Formu nākotne React

Ieviešot `experimental_useFormStatus` un ar to saistītās API, tas ir vairāk nekā tikai jauns rīks; tas atspoguļo filozofisku maiņu tajā, kā mēs veidojam interaktīvu pieredzi ar React. Aptverot tīmekļa platformas pamatus un novietojot stāvokļa loģiku uz servera, mēs varam veidot aplikācijas, kas ir vienkāršākas, noturīgākas un bieži vien veiktspējīgākas.

Mēs esam redzējuši, kā `useFormStatus` nodrošina tīru, atsaistītu veidu, kā komponentes reaģē uz formas iesniegšanas dzīves ciklu. Tas novērš prop-u padošanu gaidīšanas stāvokļiem un ļauj veidot elegantas, pašpietiekamas lietotāja saskarnes komponentes, piemēram, viedo `SubmitButton`. Apvienojumā ar `useFormState` tas atslēdz spēcīgo uz statusu balstītās validācijas modeli, kur serveris ir galvenā autoritāte, un klienta galvenā atbildība ir renderēt stāvokli, ko atgriež servera darbība.

Lai gan "eksperimentālais" marķējums prasa zināmu piesardzību, virziens ir skaidrs. Formu nākotne React ir progresīva uzlabošana, vienkāršota stāvokļa pārvaldība un spēcīga, nevainojama integrācija starp klienta un servera loģiku. Apgūstot šos jaunos hook šodien, jūs ne tikai mācāties jaunu API; jūs gatavojaties nākamās paaudzes tīmekļa aplikāciju izstrādei ar React.