Frontend Beauty
ESC

Type to search the knowledge base.

Server Actions Overview

Server Actions are async server functions callable from forms and client components: mutations, progressive enhancement, revalidation.

advanced3 min read
  • nextjs
  • server-actions

Server Actions are async functions that execute on the server, marked with "use server". You can call them from forms (progressive enhancement) or from Client Components as async functions. They are the App Router-native mutation path.

Docs: Server Actions and Mutations.

Form action

// app/actions.ts
'use server';

import { revalidatePath } from 'next/cache';

export async function createNote(formData: FormData) {
  const title = String(formData.get('title') ?? '');
  await db.notes.create({ title });
  revalidatePath('/notes');
}
// app/notes/page.tsx
import { createNote } from '../actions';

export default function NotesPage() {
  return (
    <form action={createNote}>
      <input name="title" required />
      <button type="submit">Add</button>
    </form>
  );
}

Works without client JS; with JS, Next enhances the submission.

Client invocation

'use client';
import { createNote } from '../actions';

export function AddButton() {
  return (
    <button
      type="button"
      onClick={async () => {
        await createNote(new FormData());
      }}
    >
      Quick add
    </button>
  );
}

Rules and safety

  1. Validate inputs on the server — never trust the client.
  2. Auth checks inside the action.
  3. Revalidate caches after success.
  4. Avoid huge payloads; actions are not a general RPC free-for-all without design.
  5. Closures can capture data — understand serialization boundaries.

Interview out-loud

“Server Actions are use server functions for mutations. Forms can post to them without client JS, and client code can await them. I validate and authorize on the server, then revalidatePath or revalidateTag so UI caches refresh.”

Further reading

Edge cases worth rehearsing

Interviewers and production incidents cluster around the same edges: first render versus update, empty and loading states, Strict Mode double setup, concurrent interruptions, and what happens when identity (key, route params, user id) changes mid-edit. Walk one concrete user journey end-to-end — open, edit, navigate away, come back — and say which state survives.

Prefer fixing data flow and ownership before reaching for memoization or micro-optimizations. Prefer event handlers over effects when a user action is the trigger. Prefer deriving values during render over mirroring props into state. Prefer stable list keys from business ids. Measure with the profiler when performance is the claim.

When you cite an API, mention one failure mode: abort on unmount, serializable props across server/client boundaries, focus restoration for dialogs, or cache invalidation after a mutation. Specific beats generic every time.

Edge cases worth rehearsing

Interviewers and production incidents cluster around the same edges: first render versus update, empty and loading states, Strict Mode double setup, concurrent interruptions, and what happens when identity (key, route params, user id) changes mid-edit. Walk one concrete user journey end-to-end — open, edit, navigate away, come back — and say which state survives.

Prefer fixing data flow and ownership before reaching for memoization or micro-optimizations. Prefer event handlers over effects when a user action is the trigger. Prefer deriving values during render over mirroring props into state. Prefer stable list keys from business ids. Measure with the profiler when performance is the claim.

When you cite an API, mention one failure mode: abort on unmount, serializable props across server/client boundaries, focus restoration for dialogs, or cache invalidation after a mutation. Specific beats generic every time.

Related guides