Skjemaactions: Erstatt API-ruter for mutasjoner

I tradisjonelle Next.js-applikasjoner krever skjemainnsendinger en klientkomponent med en onSubmit-behandler som bruker fetch() til å sende data med POST til en API-rute. Dette mønsteret fungerer, men krever at du skriver og vedlikeholder både fetch-logikken på klientsiden og rutebehandleren på serversiden separat.

Med Server Actions erstatter du fetch-kallet og API-ruten med én funksjon. Skjemaelementet mottar Server Action-en som sin action-prop: <form action={serverAction}>. React fanger opp innsendingen og kaller actionen automatisk med skjemadataene.

Server Action-en mottar automatisk et FormData-objekt som argument når den utløses av et skjema. Du henter enkeltfelter med formData.get('email'), som returnerer verdien som en streng. Alle standardmetodene i FormData er tilgjengelige, inkludert getAll() for felt med flervalg.

En Server Action kan returnere en serialiserbar verdi som klienten kan bruke. Hvis du returnerer et feilobjekt som { error: 'Email already exists' } eller et suksessflagg som { success: true }, kan klienten oppdatere brukergrensesnittet tilsvarende uten å laste inn hele siden på nytt.

Fordi skjemahandlingen er en Server Action, trenger ikke sidekomponenten som inneholder skjemaet å være en klientkomponent. Serveren gjengir skjemaet som statisk HTML, og bare de interaktive delene, for eksempel visning av feil, krever JavaScript på klientsiden. Dette reduserer klientpakken betydelig.

Et skjema med action={serverAction} fungerer uten at JavaScript er aktivert. Nettleseren utfører en standard HTML-POST, serveren kjører actionen, og serveren returnerer den oppdaterte siden. Denne reelle progressive forbedringen gjør at skjemaet fungerer med en god reserve i alle miljøer.

Etter at en Server Action har endret data, må bufrede sidedata oppdateres. Hvis du kaller revalidatePath('/dashboard') inne i actionen, blir Next.js-cachen for denne banen ugyldiggjort, slik at neste forespørsel henter ferske data. Dette er standardmåten å holde servergjengitte sider oppdatert etter mutasjoner.

revalidateTag('user-data') gir mer finkornet ugyldiggjøring av cache enn revalidatePath. Du merker fetch-kall med next: { tags: ['user-data'] } og ugyldiggjør deretter alle merkede data samtidig fra Server Action-en, uavhengig av hvilke baner som viser disse dataene.

Server Actions kan omdirigere brukeren til en ny side etter en vellykket mutasjon ved å kalle redirect('/success') fra modulen next/navigation. Denne omdirigeringen håndteres på serversiden, slik at nettleseren mottar et riktig navigasjonssvar i stedet for en omdirigering på klientsiden.

Server Actions er ikke begrenset til skjemainnsendinger. For knappetrykk og andre utløsere som ikke er skjemaer pakker du action-kallet inn i startTransition(() => action(arg)). Dette markerer navigasjonen som en overgang, slik at React kan holde det gjeldende brukergrensesnittet synlig mens actionen kjører på serveren.

Server Actions er det riktige stedet for validering på serversiden. Valider feltene i FormData, returner valideringsfeil hvis de ikke består, og fortsett med mutasjonen først når alle feltene er gyldige. Biblioteker som Zod integreres godt her: bruk parse til å gjøre FormData om til et typeskjema og returner feilkartet ved feil.

Server Actions erstatter fetch + API-rute-mønsteret for skjemamutasjoner. Skjemaets action-prop kan motta en Server Action direkte, og actionen mottar et FormData-objekt. Actions returnerer serialiserbare resultater for oppdateringer av brukergrensesnittet, støtter revalidatePath og revalidateTag for ugyldiggjøring av cache, og fungerer progressivt uten JavaScript.