Form Actions: ersätta API Routes för mutationer

I traditionella Next.js-applikationer kräver formulärinskickningar en Client Component med en onSubmit-hanterare som anropar fetch() för att skicka data med POST till en API-route. Mönstret fungerar, men kräver att ni skriver och underhåller både fetch-logiken på klientsidan och route-hanteraren på serversidan separat.

Med Server Actions ersätter ni fetch-anropet och API-routen med en enda funktion. Formulärelementet får Server Action som sin action-prop: <form action={serverAction}>. React fångar upp formulärinskickningen och anropar action-funktionen med formulärdata automatiskt.

Server Action tar automatiskt emot ett FormData-objekt som argument när den utlöses av ett formulär. Ni får åtkomst till enskilda fält med formData.get('email'), som returnerar värdet som en sträng. Alla vanliga FormData-metoder är tillgängliga, inklusive getAll() för fält med flera val.

En Server Action kan returnera ett serialiserbart värde som klienten kan använda. Genom att returnera ett felobjekt som { error: 'Email already exists' } eller en lyckad-status som { success: true } kan klienten uppdatera användargränssnittet därefter utan att hela sidan laddas om.

Eftersom formulärets action är en Server Action behöver sidkomponenten som innehåller formuläret inte vara en Client Component. Servern renderar formuläret som statisk HTML, och endast de interaktiva delarna, till exempel visning av fel, kräver JavaScript på klientsidan. Det minskar klientpaketet avsevärt.

Ett formulär med action={serverAction} fungerar utan aktiverat JavaScript. Webbläsaren utför en vanlig HTML-formulär-POST, servern kör action-funktionen och servern returnerar den uppdaterade sidan. Denna äkta progressiva förbättring innebär att formuläret fungerar med bibehållen grundfunktion i alla miljöer.

Efter att en Server Action har ändrat data måste cachelagrade siddata uppdateras. Om ni anropar revalidatePath('/dashboard') i action-funktionen ogiltigförklaras Next.js-cachelagret för den sökvägen, vilket gör att nästa begäran hämtar aktuella data. Detta är standardmetoden för att hålla serverrenderade sidor uppdaterade efter mutationer.

revalidateTag('user-data') ger en mer detaljerad cache-ogiltigförklaring än revalidatePath. Ni märker fetch-anrop med next: { tags: ['user-data'] } och ogiltigförklarar sedan alla märkta data samtidigt inifrån Server Action, oavsett vilka sökvägar som visar dessa data.

Server Actions kan omdirigera användaren till en ny sida efter en lyckad mutation genom att anropa redirect('/success') från modulen next/navigation. Omdirigeringen hanteras på serversidan, vilket innebär att webbläsaren får ett korrekt navigeringssvar i stället för en omdirigering på klientsidan.

Server Actions är inte begränsade till formulärinskickningar. För knappklick och andra utlösare som inte är formulär omsluter ni action-anropet med startTransition(() => action(arg)). Det markerar navigeringen som en övergång, vilket gör att React kan hålla det aktuella användargränssnittet synligt medan action-funktionen körs på servern.

Server Actions är rätt plats för validering på serversidan. Validera FormData-fälten, returnera valideringsfel om de inte godkänns och fortsätt med mutationen först när alla fält är giltiga. Bibliotek som Zod passar bra här: parsa FormData till ett typat schema och returnera felkartan om valideringen misslyckas.

Server Actions ersätter mönstret med fetch + API-route för formulärmutationer. Formulärets action-prop accepterar en Server Action direkt, som tar emot ett FormData-objekt. Actions returnerar serialiserbara resultat för uppdateringar av användargränssnittet, stöder revalidatePath och revalidateTag för cache-ogiltigförklaring och fungerar progressivt utan JavaScript.