Lomakkeiden validoinnin hallinta Reactin `experimental_useFormStatus` -hookilla

Lomakkeet ovat verkkosivujen vuorovaikutuksen peruskivi. Yksinkertaisesta uutiskirjeen tilaamisesta monimutkaiseen, monivaiheiseen rahoitushakemukseen ne ovat ensisijainen kanava, jonka kautta käyttäjät kommunikoivat sovellustemme kanssa. Silti vuosien ajan lomakkeiden tilan hallinta Reactissa on ollut monimutkaisuuden, toistuvan koodin ja riippuvuuksista johtuvan väsymyksen lähde. Olemme jonglööranneet kontrolloitujen komponenttien kanssa, taistelleet tilanhallintakirjastojen kanssa ja kirjoittaneet lukemattomia `onChange`-käsittelijöitä, kaikki saavuttaaksemme saumattoman ja intuitiivisen käyttökokemuksen.

React-tiimi on pohtinut uudelleen tätä verkkokehityksen perustavanlaatuista osa-aluetta, mikä on johtanut uuden, tehokkaan paradigman käyttöönottoon, joka keskittyy React Server Actions -toimintoihin. Tämä uusi malli, joka perustuu progressiivisen parantamisen periaatteisiin, pyrkii yksinkertaistamaan lomakkeiden käsittelyä siirtämällä logiikkaa lähemmäs sinne, minne se kuuluu – usein palvelimelle. Tämän asiakaspuolen vallankumouksen ytimessä on kaksi uutta kokeellista hookia: `useFormState` ja tämänpäiväisen keskustelumme tähti, `experimental_useFormStatus`.

Tämä kattava opas vie sinut syväsukellukselle `experimental_useFormStatus`-hookin maailmaan. Emme tarkastele vain sen syntaksia; tutkimme sen mahdollistamaa ajatusmallia: tilapohjaista validointilogiikkaa. Opit, kuinka tämä hook irrottaa käyttöliittymän lomakkeen tilasta, yksinkertaistaa odotustilojen hallintaa ja toimii yhdessä palvelintoimintojen kanssa luodakseen vankkoja, saavutettavia ja erittäin suorituskykyisiä lomakkeita, jotka toimivat jopa ennen JavaScriptin latautumista. Valmistaudu ajattelemaan uudelleen kaiken, mitä luulit tietäväsi lomakkeiden rakentamisesta Reactissa.

Paradigman muutos: React-lomakkeiden evoluutio

Ymmärtääksemme täysin `useFormStatus`-hookin tuoman innovaation, meidän on ensin ymmärrettävä lomakkeiden hallinnan matka React-ekosysteemissä. Tämä konteksti korostaa ongelmia, jotka tämä uusi lähestymistapa elegantisti ratkaisee.

Vanha kaarti: Kontrolloidut komponentit ja kolmannen osapuolen kirjastot

Vuosien ajan standardi lähestymistapa lomakkeisiin Reactissa on ollut kontrolloitujen komponenttien malli. Tämä sisältää:

• Reactin tilamuuttujan (esim. `useState`) käyttäminen kunkin lomakkeen syötekentän arvon tallentamiseen.
• `onChange`-käsittelijän kirjoittaminen tilan päivittämiseksi jokaisella näppäinpainalluksella.
• Tilamuuttujan välittäminen takaisin syötekentän `value`-attribuuttiin.

Vaikka tämä antaa Reactille täyden hallinnan lomakkeen tilasta, se lisää merkittävästi toistuvaa koodia. Kymmenen kentän lomakkeeseen saatat tarvita kymmenen tilamuuttujaa ja kymmenen käsittelijäfunktiota. Validoinnin, virhetilojen ja lähetystilan hallinta lisäävät monimutkaisuutta entisestään, mikä usein johtaa kehittäjät luomaan monimutkaisia omia hookeja tai turvautumaan kattaviin kolmannen osapuolen kirjastoihin.

Kirjastot kuten Formik ja React Hook Form nousivat suosioon abstrahoimalla tämän monimutkaisuuden. Ne tarjoavat loistavia ratkaisuja tilanhallintaan, validointiin ja suorituskyvyn optimointiin. Ne ovat kuitenkin yksi riippuvuus lisää hallittavaksi ja toimivat usein kokonaan asiakaspuolella, mikä voi johtaa päällekkäiseen validointilogiikkaan front-endin ja back-endin välillä.

Uusi aikakausi: Progressiivinen parantaminen ja palvelintoiminnot

React Server Actions -toiminnot tuovat mukanaan paradigman muutoksen. Ydinidea on rakentaa web-alustan perustalle: standardille HTML:n `

`-elementille. Palvelintoiminnolla varustettu lomake toimii kuten klassinen HTML-lomakkeen lähetys – se voi toimia täydellisesti, vaikka JavaScript epäonnistuisi tai olisi poissa käytöstä. Tämä on progressiivisen parantamisen ydin.

Kun JavaScript latautuu, React kaappaa lomakkeen lähetysprosessin, estää koko sivun uudelleenlatauksen ja suorittaa palvelintoiminnon asynkronisesti. Tämä antaa meille parhaat puolet molemmista maailmoista: palvelimella renderöityjen sovellusten kestävyyden ja yksisivuisen sovelluksen (SPA) rikkaan, interaktiivisen kokemuksen.

Tämä malli siirtää liiketoimintalogiikan ja validoinnin totuuden lähteen takaisin palvelimelle (tai palvelimen kaltaiseen ympäristöön). Asiakaspuolen koodista tulee yksinkertaisempaa, ja se keskittyy pääasiassa käyttöliittymän renderöintiin tuon palvelinkommunikaation *tilan* perusteella. Juuri tähän `useFormStatus` astuu kuvaan.

Konepellin alla: Mikä on `experimental_useFormStatus`?

`experimental_useFormStatus`-hook on asiakaspuolen työkalu, joka on suunniteltu antamaan tietoa vanhempana olevan ``-elementin viimeisimmästä lähetyksestä. Se on vain luku -tyyppinen hook, joka kertoo komponentille kaiken, mitä sen tarvitsee tietää lomakkeen lähetystilasta ilman, että sille tarvitsee välittää propseja.

Ydintoiminnallisuus

Kuvittele lähetyspainike suuren lomakkeen sisällä. Miten tämä painike tietää, milloin lomaketta lähetetään? Perinteisesti sinun olisi pitänyt välittää `isSubmitting`-kaltainen tilamuuttuja useiden komponenttikerrosten läpi (prop drilling). `useFormStatus`-hookin avulla painikekomponentti voi selvittää tämän tiedon itse.

Hookia on kutsuttava komponentista, joka renderöidään *sisällä* ``-elementtiä. Se antaa tällöin tilatietoa kyseisen lomakkeen elinkaaresta.

`useFormStatus`-hookin anatomia

Kun kutsut `const status = useFormStatus()`, saat takaisin olion, jolla on seuraavat avainominaisuudet:

• `pending` (boolean): Tämä on useimmin käytetty ominaisuus. Se on `true`, jos vanhempi lomake on parhaillaan lähetyksessä, ja muuten `false`. Se on täydellinen painikkeiden poistamiseen käytöstä, latausindikaattoreiden näyttämiseen tai odotustilojen tyylittelyyn.
• `data` (FormData): Olio, joka toteuttaa `FormData`-rajapinnan. Se sisältää lomakkeen mukana lähetetyt tiedot. Tämä on uskomattoman hyödyllinen optimististen käyttöliittymäpäivitysten toteuttamisessa – esimerkiksi käyttäjän kommentin näyttäminen listassa heti sen lähettämisen jälkeen, jopa ennen kuin palvelin on vahvistanut sen luomisen.
• `method` (string): HTTP-metodi ('get' tai 'post'), jota käytettiin lomakkeen lähetyksessä.
• `action` (function): Viittaus palvelintoimintofunktioon, joka käynnistettiin lähetyksen aikana.

Kultainen sääntö: ``-elementin lapsi

Kriittinen sääntö muistaa on, että `useFormStatus`-hookia käyttävän komponentin on oltava renderöitynä sen ``-elementin lapsena, jota se seuraa. Se ei voi olla samassa komponentissa, joka renderöi itse ``-tagin, koska sen on päästävä käsiksi lomakkeen kontekstiin. Siksi näet lähes aina erikseen luotuja komponentteja, kuten ``, jotka sisältävät `useFormStatus`-logiikan.

Yksinkertainen esimerkki: Älykäs lähetyspainike

Katsotaanpa yleisintä käyttötapausta käytännössä. Standardin ``-elementin sijaan luomme komponentin, joka on tietoinen lomakkeen lähetystilasta.

Tiedosto: SubmitButton.js

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

{pending ? 'Lähetetään...' : 'Rekisteröidy'} ); }

Tiedosto: SignUpForm.js

import { SubmitButton } from './SubmitButton'; import { signUpAction } from './actions'; // Palvelintoiminto export function SignUpForm() { return ( Sähköposti:
); }

Tässä esimerkissä `SubmitButton` on täysin itsenäinen. Se ei vastaanota propseja. Se käyttää `useFormStatus`-hookia tietääkseen, milloin `SignUpForm` on odotustilassa, ja poistaa itsensä automaattisesti käytöstä ja muuttaa tekstiään. Tämä on tehokas malli vastuunjaolle ja uudelleenkäytettävien, lomaketietoisien komponenttien luomiseen.

Asian ydin: Tilapohjainen validointilogiikka

Nyt pääsemme ydinkäsitteeseen. `useFormStatus` ei ole tarkoitettu vain lataustiloille; se on keskeinen mahdollistaja erilaiselle tavalle ajatella validointia.

"Tilavalidoinnin" määrittely

Tilapohjainen validointi on malli, jossa validointipalaute annetaan käyttäjälle pääasiassa vastauksena lomakkeen lähetysyritykseen. Sen sijaan, että validointi tehtäisiin jokaisella näppäinpainalluksella (`onChange`) tai kun käyttäjä poistuu kentästä (`onBlur`), pääasiallinen validointilogiikka suoritetaan, kun käyttäjä lähettää lomakkeen. Tämän lähetyksen tulosta – sen *tilaa* (esim. onnistuminen, validointivirhe, palvelinvirhe) – käytetään sitten käyttöliittymän päivittämiseen.

Tämä lähestymistapa sopii täydellisesti yhteen React Server Actions -toimintojen kanssa. Palvelintoiminnosta tulee validoinnin ainoa totuuden lähde. Se vastaanottaa lomaketiedot, validoi ne liiketoimintasääntöjäsi vastaan (esim. "onko tämä sähköpostiosoite jo käytössä?") ja palauttaa jäsennellyn tilaobjektin, joka ilmaisee lopputuloksen.

Sen kumppanin rooli: `experimental_useFormState`

`useFormStatus` kertoo meille *mitä* tapahtuu (odotustila), mutta se ei kerro meille, *mikä* oli lopputulos. Sitä varten tarvitsemme sen sisar-hookin: `experimental_useFormState`.

`useFormState` on hook, joka on suunniteltu päivittämään tilaa lomaketoiminnon tuloksen perusteella. Se ottaa argumenteikseen toimintofunktion ja alkutilan ja palauttaa uuden tilan sekä käärityn toimintofunktion, joka välitetään lomakkeelle.

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

• `state`: Tämä sisältää `myAction`-toiminnon viimeisimmän suorituksen palautusarvon. Täältä saamme virheilmoituksemme.
• `formAction`: Tämä on uusi versio toiminnostasi, joka sinun tulisi välittää `
  `-elementin `action`-attribuuttiin. Kun tätä kutsutaan, se käynnistää alkuperäisen toiminnon ja päivittää `state`-muuttujan.

Yhdistetty työnkulku: Klikkauksesta palautteeseen

Näin `useFormState` ja `useFormStatus` toimivat yhdessä luodakseen täydellisen validointisyklin:

1. Ensimmäinen renderöinti: Lomake renderöidään `useFormState`:n tarjoamalla alkutilalla. Virheitä ei näytetä.
2. Käyttäjän lähetys: Käyttäjä napsauttaa lähetyspainiketta.
3. Odotustila: Lähetyspainikkeen `useFormStatus`-hook ilmoittaa välittömästi `pending: true`. Painike poistuu käytöstä ja näyttää latausviestin.
4. Toiminnon suoritus: Palvelintoiminto (`useFormState`:n käärimänä) suoritetaan lomaketiedoilla. Se suorittaa validoinnin.
5. Toiminto palauttaa: Toiminnon validointi epäonnistuu ja se palauttaa tilaobjektin, esimerkiksi:
   `{ message: "Validation failed", errors: { email: "This email is already taken." } }`
6. Tilan päivitys: `useFormState` vastaanottaa tämän palautusarvon ja päivittää `state`-muuttujansa. Tämä käynnistää lomakekomponentin uudelleenrenderöinnin.
7. Käyttöliittymäpalaute: Lomake renderöidään uudelleen. `useFormStatus`:n `pending`-tila muuttuu `false`:ksi. Komponentti voi nyt lukea `state.errors.email`-arvon ja näyttää virheilmoituksen sähköpostikentän vieressä.

Koko tämä työnkulku antaa käyttäjälle selkeää, palvelimen vahvistamaa palautetta, joka perustuu täysin lähetyksen tilaan ja tulokseen.

Käytännön mestarikurssi: Monikenttäisen rekisteröintilomakkeen rakentaminen

Vahvistetaan näitä käsitteitä rakentamalla täydellinen, tuotantotyylinen rekisteröintilomake. Käytämme palvelintoimintoa validointiin ja sekä `useFormState`- että `useFormStatus`-hookeja luodaksemme loistavan käyttökokemuksen.

Vaihe 1: Palvelintoiminnon määrittely validoinnilla

Ensin tarvitsemme palvelintoimintomme. Vankkaa validointia varten käytämme suosittua Zod-kirjastoa. Tämä toiminto sijoitetaan erilliseen tiedostoon, joka on merkitty `'use server';`-direktiivillä, jos käytät Next.js:n kaltaista kehystä.

Tiedosto: actions/authActions.js

'use server'; import { z } from 'zod'; // Määritellään validointiskeema const registerSchema = z.object({ username: z.string().min(3, 'Käyttäjänimen on oltava vähintään 3 merkkiä pitkä.'), email: z.string().email('Anna kelvollinen sähköpostiosoite.'), password: z.string().min(8, 'Salasanan on oltava vähintään 8 merkkiä pitkä.'), }); // Määritellään lomakkeen alkutila export const initialState = { message: '', errors: {}, }; export async function registerUser(prevState, formData) { // 1. Validoidaan lomaketiedot const validatedFields = registerSchema.safeParse( Object.fromEntries(formData.entries()) ); // 2. Jos validointi epäonnistuu, palautetaan virheet if (!validatedFields.success) { return { message: 'Validointi epäonnistui. Tarkista kentät.', errors: validatedFields.error.flatten().fieldErrors, }; } // 3. (Simuloidaan) Tarkistetaan, onko käyttäjä jo olemassa tietokannassa // Oikeassa sovelluksessa tekisit tietokantakyselyn tässä. if (validatedFields.data.email === 'user@example.com') { return { message: 'Rekisteröinti epäonnistui.', errors: { email: ['Tämä sähköpostiosoite on jo rekisteröity.'] }, }; } // 4. (Simuloidaan) Luodaan käyttäjä console.log('Luodaan käyttäjä:', validatedFields.data); // 5. Palautetaan onnistunut tila // Oikeassa sovelluksessa voisit uudelleenohjata tässä käyttämällä `redirect()`-funktiota paketista 'next/navigation' return { message: 'Käyttäjä rekisteröityi onnistuneesti!', errors: {}, }; }

Tämä palvelintoiminto on lomakkeemme aivot. Se on itsenäinen, turvallinen ja tarjoaa selkeän tietorakenteen sekä onnistumis- että virhetiloille.

Vaihe 2: Uudelleenkäytettävien, tilatietoisten komponenttien rakentaminen

Pitääksemme pääkomponenttimme siistinä, luomme omat komponentit syötekentillemme ja lähetyspainikkeelle.

Tiedosto: components/SubmitButton.js

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

Huomaa `aria-disabled={pending}`-attribuutin käyttö. Tämä on tärkeä saavutettavuuskäytäntö, joka varmistaa, että ruudunlukijat ilmoittavat poistetun tilan oikein.

Vaihe 3: Pääkomponentin kokoaminen `useFormState`-hookilla

Nyt tuodaan kaikki yhteen pääkomponentissamme. Käytämme `useFormState`-hookia yhdistääksemme käyttöliittymämme `registerUser`-toimintoon.

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

Rekisteröidy

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

{state.message}

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

{state.message}

}

Käyttäjänimi {state?.errors?.username && (

{state.errors.username[0]}

)}

Sähköposti {state?.errors?.email && (

{state.errors.email[0]}

)}

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

{state.errors.password[0]}

)}

); }

Tämä komponentti on nyt deklaratiivinen ja siisti. Se ei hallitse mitään tilaa itse, lukuun ottamatta `useFormState`-hookin tarjoamaa `state`-oliota. Sen ainoa tehtävä on renderöidä käyttöliittymä tuon tilan perusteella. Painikkeen käytöstä poistamisen logiikka on kapseloitu `SubmitButton`-komponenttiin, ja kaikki validointilogiikka sijaitsee tiedostossa `authActions.js`. Tämä vastuunjako on valtava voitto ylläpidettävyyden kannalta.

Edistyneet tekniikat ja ammattimaiset parhaat käytännöt

Vaikka perusmalli on tehokas, todellisen maailman sovellukset vaativat usein enemmän hienovaraisuutta. Tutustutaan joihinkin edistyneisiin tekniikoihin.

Hybridimalli: Välittömän ja lähetyksen jälkeisen validoinnin yhdistäminen

Tilapohjainen validointi on erinomainen palvelinpuolen tarkistuksiin, mutta verkkokierroksen odottaminen käyttäjän virheellisen sähköpostin ilmoittamiseksi voi olla hidasta. Hybridimalli on usein paras:

• Käytä HTML5-validointia: Älä unohda perusteita! Attribuutit kuten `required`, `type="email"`, `minLength` ja `pattern` antavat välitöntä, selaimen natiivia palautetta ilman lisäkustannuksia.
• Kevyt asiakaspuolen validointi: Puhtaasti kosmeettisiin tai muotoilutarkistuksiin (esim. salasanan vahvuuden ilmaisin) voit edelleen käyttää pienen määrän `useState`- ja `onChange`-käsittelijöitä.
• Palvelinpuolen auktoriteetti: Varaa palvelintoiminto kriittisimmälle liiketoimintalogiikan validoinnille, jota ei voi tehdä asiakaspuolella (esim. uniikkien käyttäjänimien tarkistaminen, validointi tietokantatietoja vastaan).

Tämä antaa sinulle parhaat puolet molemmista maailmoista: välitöntä palautetta yksinkertaisista virheistä ja auktoritatiivista validointia monimutkaisille säännöille.

Saavutettavuus (A11y): Lomakkeiden rakentaminen kaikille

Saavutettavuus ei ole neuvoteltavissa. Kun toteutat tilapohjaista validointia, pidä nämä seikat mielessä:

• Ilmoita virheistä: Esimerkissämme käytimme `aria-live="polite"`-attribuuttia virheilmoitusten säiliöissä. Tämä kertoo ruudunlukijoille, että niiden tulee ilmoittaa virheilmoitus heti sen ilmestyessä keskeyttämättä käyttäjän nykyistä toimintaa.
• Yhdistä virheet syötekenttiin: Vankemman yhteyden saamiseksi käytä `aria-describedby`-attribuuttia. Syötekenttä voi osoittaa virheilmoitussäiliönsä ID:hen, mikä luo ohjelmallisen linkin.
• Fokuksen hallinta: Virheitä sisältävän lähetyksen jälkeen harkitse fokuksen siirtämistä ohjelmallisesti ensimmäiseen virheelliseen kenttään. Tämä säästää käyttäjiltä vaivan etsiä, mikä meni pieleen.

Optimistinen käyttöliittymä `useFormStatus`-hookin `data`-ominaisuudella

Kuvittele sosiaalisen median sovellus, jossa käyttäjä julkaisee kommentin. Sen sijaan, että näyttäisit latausindikaattoria sekunnin ajan, voit saada sovelluksen tuntumaan välittömältä. `useFormStatus`-hookin `data`-ominaisuus on täydellinen tähän.

Kun lomake lähetetään, `pending` muuttuu todeksi ja `data` täyttyy lähetyksen `FormData`-tiedoilla. Voit välittömästi renderöidä uuden kommentin väliaikaisessa, 'odottavassa' visuaalisessa tilassa käyttämällä tätä `data`-tietoa. Jos palvelintoiminto onnistuu, korvaat odottavan kommentin lopullisilla tiedoilla palvelimelta. Jos se epäonnistuu, voit poistaa odottavan kommentin ja näyttää virheilmoituksen. Tämä saa sovelluksen tuntumaan uskomattoman responsiiviselta.

Navigointi "kokeellisilla" vesillä

On ratkaisevan tärkeää käsitellä "experimental"-etuliitettä hookeissa `experimental_useFormStatus` ja `experimental_useFormState`.

Mitä "kokeellinen" todella tarkoittaa

Kun React leimaa APIn kokeelliseksi, se tarkoittaa:

• API voi muuttua: Nimi, argumentit tai palautusarvot voivat muuttua tulevassa React-julkaisussa noudattamatta standardia semanttista versiointia (SemVer) rikkovien muutosten osalta.
• Siinä voi olla bugeja: Uutena ominaisuutena siinä voi olla reunatapauksia, joita ei ole vielä täysin ymmärretty tai ratkaistu.
• Dokumentaatio voi olla niukkaa: Vaikka ydinasiat on dokumentoitu, yksityiskohtaiset oppaat edistyneistä malleista voivat vielä olla kehittymässä.

Milloin ottaa käyttöön ja milloin odottaa

Joten, pitäisikö sinun käyttää sitä projektissasi? Vastaus riippuu kontekstistasi:

• Hyvä valinta: Henkilökohtaiset projektit, sisäiset työkalut, startupit tai tiimit, jotka ovat tottuneet hallitsemaan mahdollisia API-muutoksia. Sen käyttäminen Next.js:n kaltaisessa kehyksessä (joka on integroinut nämä ominaisuudet App Routeriinsa) on yleensä turvallisempi veto, koska kehys voi auttaa abstrahoimaan osan muutoksista.
• Käytä varoen: Suuren mittakaavan yrityssovellukset, kriittiset järjestelmät tai projektit, joilla on pitkäaikaiset ylläpitosopimukset ja joissa API:n vakaus on ensisijaisen tärkeää. Näissä tapauksissa voi olla viisasta odottaa, kunnes hookit ylennetään vakaaksi API:ksi.

Pidä aina silmällä virallista React-blogia ja dokumentaatiota ilmoitusten varalta näiden hookien vakiinnuttamisesta.

Johtopäätös: Lomakkeiden tulevaisuus Reactissa

`experimental_useFormStatus`-hookin ja siihen liittyvien APIen esittely on enemmän kuin vain uusi työkalu; se edustaa filosofista muutosta siinä, miten rakennamme interaktiivisia kokemuksia Reactilla. Hyväksymällä web-alustan perusteet ja sijoittamalla tilallisen logiikan palvelimelle voimme rakentaa sovelluksia, jotka ovat yksinkertaisempia, kestävämpiä ja usein suorituskykyisempiä.

Olemme nähneet, kuinka `useFormStatus` tarjoaa siistin, erotetun tavan komponenteille reagoida lomakkeen lähetyssykliin. Se poistaa prop drillingin odotustiloille ja mahdollistaa elegantit, itsenäiset käyttöliittymäkomponentit, kuten älykkään `SubmitButton`-painikkeen. Yhdistettynä `useFormState`-hookiin se avaa tehokkaan tilapohjaisen validoinnin mallin, jossa palvelin on lopullinen auktoriteetti ja asiakaspuolen päävastuu on renderöidä palvelintoiminnon palauttama tila.

Vaikka "kokeellinen"-merkintä vaatii tiettyä varovaisuutta, suunta on selvä. Lomakkeiden tulevaisuus Reactissa on progressiivisen parantamisen, yksinkertaistetun tilanhallinnan ja tehokkaan, saumattoman integraation asiakas- ja palvelinlogiikan välillä. Hallitsemalla nämä uudet hookit tänään et ainoastaan opi uutta APIa; valmistaudut seuraavan sukupolven verkkosovelluskehitykseen Reactilla.