## The Problem with Traditional API Mutations Imagine you're building a Todo app. The user types: ```text Learn Next.js ``` and clicks: ```text Add Todo ``` Sounds simple. But in a traditional client-heavy [React](/courses/reactjs) application, you might need to: ```text 1. Create input state 2. Write onChange 3. Write onSubmit 4. Prevent default form behavior 5. Set loading state 6. Call fetch("/api/todos") 7. Create POST /api/todos 8. Parse JSON 9. Validate data 10. Connect to database 11. Insert todo 12. Return JSON 13. Parse JSON again on client 14. Update UI 15. Handle errors ``` All because the user wanted to save: ```text "Buy milk" ``` 😭 Nothing is technically wrong with APIs. Route Handlers are still extremely useful. But when the mutation is only being used by **your own [Next.js](/courses/nextjs) application**, creating a separate HTTP API endpoint can sometimes be unnecessary boilerplate. That's where **Server [Functions](/javascript/functions-in-javascript)** and **Server Actions** come in. --- # What is a Server Function? A Server [Function](/javascript/functions-in-javascript) is an [asynchronous](/javascript/promises-asynchronous-javascript) function that runs on the server and can be invoked from your [React](/courses/reactjs) application. Example: ```js async function createTodo(formData) { "use server" const title = formData.get("title") await db.todo.create({ data: { title } }) } ``` That function executes on the server. So it can safely access things such as: - Databases - Private environment variables - Authentication sessions - Backend SDKs - Server-only libraries --- > **Definition: Server Function** > > A Server Function is an [asynchronous](/javascript/promises-asynchronous-javascript) function marked with `"use server"` that executes on the server but can be invoked from Server or Client Components through [Next.js](/courses/nextjs). --- # Server Function vs Server Action You'll hear both names. They are related, but technically not identical. Think: ```text Server Function = Broad concept ``` When that Server Function is used for an action or mutation such as: ```text Create Todo Delete Post Update Profile Submit Form ``` it is commonly called a: ```text Server Action ``` So: ```text Server Function ↓ Used for mutation/action ↓ Server Action ``` In everyday Next.js conversations, developers still commonly say: ```text Server Actions ``` for this whole pattern. --- # What Does `"use server"` Do? This directive: ```js "use server" ``` tells React and Next.js: > "This function must execute on the server." Example: ```js async function createPost() { "use server" // Server-only work } ``` You can also put: ```js "use server" ``` at the top of an entire file. Example: ```js "use server" export async function createPost() { // ... } export async function deletePost() { // ... } export async function updatePost() { // ... } ``` Now all exported functions in that file are Server Functions. --- # Server Functions Must Be Async Server Functions must be asynchronous. Correct: ```js export async function createTodo() { // ... } ``` Not: ```js export function createTodo() { // ❌ } ``` Why? Because Client Components invoke Server Functions through a network request. So Next.js needs them to follow the asynchronous server-function model. --- # What Happens Behind the Scenes? This: ```jsx

``` looks like you're calling a normal [JavaScript](/courses/javascript) function. But the browser obviously cannot directly execute your database code. Behind the scenes, Next.js creates the infrastructure required to send the action to the server. Conceptually: ```text User submits form ↓ Browser sends POST ↓ Next.js identifies Server Action ↓ Server executes function ↓ Database updates ↓ Server returns updated result/UI ``` You don't manually create: ```text POST /api/todos ``` for this mutation. Next.js handles the communication layer for you. 🔥 --- > **Interview Highlight** > > **Q: Do Server Actions actually run directly inside the browser?** > > No. Server Actions execute on the server. When invoked from the browser, Next.js sends a network request to the server and executes the associated Server Function there. --- # 1. Server Action Inside a Server Component The simplest approach is defining an action directly inside a Server Component. Example: ```jsx import { revalidatePath } from "next/cache" export default async function TodoPage() { async function createTodo( formData ) { "use server" const title = formData.get("title") await db.todo.create({ data: { title } }) revalidatePath( "/todos" ) } const todos = await db.todo.findMany() return (

{todo.title}

) } ``` This is one of those moments where Next.js feels almost suspiciously simple. 😄 --- # Notice What We Didn't Write There's no: ```js onSubmit={} ``` No: ```js fetch("/api/todos") ``` No: ```text /api/todos/route.js ``` No: ```js JSON.stringify() ``` No: ```js response.json() ``` The form sends its: ```text FormData ``` directly to the Server Action. --- # The ` ``` Action: ```js async function createUser( formData ) { "use server" const name = formData.get("name") const email = formData.get("email") console.log({ name, email }) } ``` Very clean. --- # Progressive Enhancement Here's another cool feature. Forms using Server Actions from [Server Components](/courses/nextjs) can work even if the browser's [JavaScript](/courses/javascript) hasn't finished loading yet. Conceptually: ```text HTML loads ↓ JavaScript still loading ↓ User submits form ↓ Server Action can still execute ``` This is called: **Progressive Enhancement** Your basic form behavior doesn't have to depend entirely on client-side JavaScript. That's pretty powerful. --- # 2. Revalidating the UI After creating a Todo: ```js await db.todo.create(...) ``` the database has changed. But your page may still contain cached data. Next.js gives you: ```js revalidatePath() ``` Example: ```js import { revalidatePath } from "next/cache" revalidatePath("/todos") ``` This tells Next.js: > "The data associated with `/todos` has changed. Refresh the relevant cached content." So the general mutation flow becomes: ```text User submits ↓ Server Action ↓ Database changes ↓ revalidatePath() ↓ UI gets fresh data ``` --- # Create + Revalidate Example ```js "use server" import { revalidatePath } from "next/cache" export async function createTodo( formData ) { const title = formData.get("title") await db.todo.create({ data: { title } }) revalidatePath( "/todos" ) } ``` No manual client-side refetch logic required. Nice. --- # `refresh()` — Another Modern Option Modern Next.js also provides: ```js refresh() ``` from: ```js next/cache ``` inside Server Actions. Example: ```js "use server" import { refresh } from "next/cache" export async function createTodo( formData ) { await db.todo.create({ data: { title: formData.get("title") } }) refresh() } ``` This refreshes the client router after the Server Action completes. Think: ```text revalidatePath() ↓ Invalidate specific cached route data ``` versus: ```text refresh() ↓ Refresh current client router data ``` Use the option that matches your mutation. --- # 3. Server Actions in Separate Files As your application grows, putting every action inside: ```text page.jsx ``` gets messy. You can create a dedicated file. For example: ```text src/actions/todoActions.js ``` Then: ```js "use server" import { revalidatePath } from "next/cache" export async function createTodo( formData ) { const title = formData.get("title") await db.todo.create({ data: { title } }) revalidatePath( "/todos" ) } export async function deleteTodo( id ) { await db.todo.delete({ where: { id } }) revalidatePath( "/todos" ) } ``` The top-level: ```js "use server" ``` means every exported function in this file is a Server Function. --- # Why Separate Action Files Are Useful They keep your application organized. For example: ```text src/ ├── actions/ │ ├── todoActions.js │ ├── userActions.js │ ├── postActions.js │ └── authActions.js │ └── app/ ``` Now: ```text Todo mutations ``` live together. ```text User mutations ``` live together. Much easier than hiding 47 database functions across random components. --- # Client Components Cannot Define Server Functions Inline This is important. A Client Component cannot do this: ```jsx "use client" export default function Button() { async function deleteUser() { "use server" // ❌ } } ``` You cannot define a Server Function inside a Client Component. Instead, create it in a separate: ```js "use server" ``` file. Then import it. --- # Client Component + Server Action Server file: ```js // actions/todoActions.js "use server" export async function deleteTodo( id ) { await db.todo.delete({ where: { id } }) } ``` Client Component: ```jsx "use client" import { deleteTodo } from "@/actions/todoActions" export default function DeleteButton({ id }) { return ( ) } ``` It looks like a normal function call. But remember: ```text Client ↓ Network request ↓ Server ↓ deleteTodo() ``` Don't let the syntax fool you. --- # Calling Actions with `useTransition` If you want pending UI when manually calling a Server Action, React's: ```js useTransition() ``` is useful. Example: ```jsx "use client" import { useTransition } from "react" import { deleteTodo } from "@/actions/todoActions" export default function DeleteButton({ id }) { const [ isPending, startTransition ] = useTransition() function handleDelete() { startTransition(() => { deleteTodo(id) }) } return ( ) } ``` Now: ```text User clicks Delete ↓ isPending = true ↓ Server Action runs ↓ Action completes ↓ isPending = false ``` Much better UX. --- # Server Actions and Serializable Data Because values may cross the network boundary, Server Function arguments and return values need to follow React's supported serialization rules. Common values such as these are straightforward: ```js "hello" ``` ```js 123 ``` ```js true ``` ```js { name: "Asif" } ``` ```js ["react", "nextjs"] ``` and: ```text FormData ``` are common patterns. Don't think of Server Functions as: > "Any random JavaScript object can teleport between browser and server." There's still a serialization boundary. --- # 4. Passing Extra Arguments Sometimes your action needs more than form data. Imagine: ```text Update user 123 ``` The form provides: ```text name ``` but the action also needs: ```text userId ``` One approach is JavaScript: ```js .bind() ``` --- # Using `bind()` Server Action: ```js "use server" export async function updateUser( userId, formData ) { const name = formData.get("name") await db.user.update({ where: { id: userId }, data: { name } }) } ``` Component: ```jsx import { updateUser } from "@/actions/userActions" export default function UserForm({ userId }) { const updateUserWithId = updateUser.bind( null, userId ) return ( ) } ``` Now the Server Action receives: ```text userId ``` plus: ```text formData ``` --- # Why Not Just Use a Hidden Input? You could write: ```jsx ``` That's valid for some use cases. But remember: > Hidden does not mean secure. The value still exists in the HTML and can be modified by the user. And even values passed through: ```js bind() ``` should never automatically be trusted for authorization. Always verify sensitive identifiers on the server. --- # 5. Pending States with `useFormStatus` When a form submits, you usually want to show: ```text Saving... ``` instead of allowing the user to click: ```text Submit Submit Submit Submit Submit ``` until your database starts questioning its career choices. 😭 React provides: ```js useFormStatus() ``` --- # Submit Button Example ```jsx "use client" import { useFormStatus } from "react-dom" export function SubmitButton() { const { pending } = useFormStatus() return ( ) } ``` Then: ```jsx

``` Now the button automatically knows whether its parent form is submitting. --- # The Critical `useFormStatus()` Rule This won't work properly: ```jsx function TodoForm() { const { pending } = useFormStatus() return ( ) } ``` Why? Because: ```js useFormStatus() ``` reads the status of a **parent form**. The form created by the same component is not its parent. --- # Correct Structure ```text TodoForm └──

├── input └── SubmitButton └── useFormStatus() ``` So: ```jsx function TodoForm() { return ( ) } ``` and: ```jsx "use client" import { useFormStatus } from "react-dom" function SubmitButton() { const { pending } = useFormStatus() return ( ) } ``` --- > **Interview Highlight** > > **Q: Why must `useFormStatus()` be used inside a child component of the form?** > > Because `useFormStatus()` reads the submission state of its parent `

`. It does not track a form rendered by the same component calling the hook. --- # `useFormStatus()` Gives More Than `pending` Modern React returns information including: ```js const { pending, data, method, action } = useFormStatus() ``` The most commonly used value is: ```js pending ``` But: ```js data ``` can expose the FormData currently being submitted. For example: ```jsx const { pending, data } = useFormStatus() return (

{pending ? `Saving ${data?.get("title")}...` : ""}

) ``` Useful for more advanced form UX. --- # 6. Handling Expected Errors with `useActionState` What happens if the user submits: ```text email = "banana" ``` You don't necessarily want to throw a giant server exception. That's an **expected validation error**. React provides: ```js useActionState() ``` for handling action results. --- # Server Action ```js "use server" export async function registerUser( previousState, formData ) { const email = formData.get("email") if ( typeof email !== "string" || !email.includes("@") ) { return { error: "Please enter a valid email.", success: false, } } await db.user.create({ data: { email } }) return { error: null, success: true, } } ``` Notice that when used with: ```js useActionState() ``` the Server Action receives: ```text previousState ``` first, then: ```text formData ``` second. That's important. --- # Client Form with `useActionState` ```jsx "use client" import { useActionState } from "react" import { registerUser } from "@/actions/authActions" const initialState = { error: null, success: false, } export default function RegisterForm() { const [ state, formAction, isPending ] = useActionState( registerUser, initialState ) return ( {state.error && (

{state.error}

)} {state.success && (

Account created!

)}

) } ``` Now the data flow becomes: ```text Form submits ↓ Server Action ↓ Validation ↓ Return state ↓ useActionState() ↓ UI updates ``` No manual: ```js fetch() ``` required. --- # What Does `useActionState()` Return? ```js const [ state, formAction, isPending ] = useActionState( action, initialState ) ``` You get: ### `state` The latest value returned by your action. --- ### `formAction` The function you pass to: ```jsx

``` --- ### `isPending` Whether the Action is currently running. So you can disable buttons and display loading UI. --- # Expected Errors vs Unexpected Errors There are two broad types of errors. ### Expected Error Examples: ```text Email already exists Invalid password Missing title Insufficient balance Product out of stock ``` These should usually become **return values**. Example: ```js return { error: "Email already exists" } ``` Then show them in the UI using: ```js useActionState() ``` --- ### Unexpected Error Examples: ```text Database crashed Programming bug Unexpected exception ``` These can be thrown: ```js throw new Error( "Unable to create user" ) ``` and handled through the nearest Next.js error boundary. Think: ```text Expected problem ↓ Return useful state ``` ```text Unexpected failure ↓ Throw error ``` --- # 7. Validation Is Mandatory Never trust: ```js formData ``` because: > "The form has `required` on the input." A malicious client doesn't have to use your form. They can send requests directly. So server-side validation is mandatory. --- # Validation with Zod Example: ```js "use server" import { z } from "zod" const TodoSchema = z.object({ title: z .string() .min(1) .max(200) }) export async function createTodo( previousState, formData ) { const result = TodoSchema.safeParse({ title: formData.get( "title" ) }) if (!result.success) { return { error: "Invalid todo title" } } await db.todo.create({ data: { title: result.data.title } }) return { error: null } } ``` Now the server decides what data is valid. Not the browser. --- # 8. Authentication Inside Server Actions This is extremely important. Suppose you have: ```js "use server" export async function deletePost( id ) { await db.post.delete({ where: { id } }) } ``` Looks convenient. Also potentially terrifying. 💀 A Server Action can be reached through a network request. So don't assume: > "Only my Delete button can call this." The server must verify the user. --- # Secure Delete Action ```js "use server" import { auth } from "@/auth" export async function deletePost( id ) { const session = await auth() if (!session?.user) { throw new Error( "Unauthorized" ) } const post = await db.post.findUnique({ where: { id } }) if (!post) { throw new Error( "Post not found" ) } if ( post.authorId !== session.user.id ) { throw new Error( "Forbidden" ) } await db.post.delete({ where: { id } }) } ``` Now we're checking: ```text Is user logged in? ↓ Does post exist? ↓ Does this user own it? ↓ Delete ``` That's real authorization. --- > **Interview Highlight** > > **Q: Are Server Actions automatically secure because they run on the server?** > > No. Server Actions are reachable through network requests and should be treated like public-facing mutation endpoints. Validate input, authenticate the user, and authorize every sensitive operation inside the action. --- # Server-Side Does NOT Mean Trusted Input This is worth repeating. Server Actions run securely on your server. But the **arguments sent to them originate from the client**. So this: ```js deletePost(postId) ``` doesn't mean: ```text postId is trustworthy ``` Users can potentially manipulate request data. Always treat action arguments as untrusted input. --- # Bad Authorization ```js export async function deletePost( postId, userId ) { // ❌ Trusting userId from browser await db.post.delete({ where: { id: postId, authorId: userId } }) } ``` A malicious user could potentially provide somebody else's: ```text userId ``` Instead, derive identity from your trusted session: ```js const session = await auth() ``` Then use: ```js session.user.id ``` for authorization. --- # 9. Server Actions Use POST Behind the scenes, Server Actions use: ```text POST ``` requests. This makes sense because actions generally perform mutations. Conceptually: ```text Client ↓ POST ↓ Server Function ↓ Mutation ``` You don't choose: ```text GET PUT PATCH DELETE ``` like you would with a [REST API](/courses/expressjs). If you need a traditional HTTP API with explicit methods, use: ```text Route Handlers ``` instead. --- # Server Actions vs Route Handlers This is an important architectural distinction. ### Server Action Best when: ```text Your own Next.js UI needs to mutate server data. ``` Example: ```text Submit form Delete todo Update profile Like post ``` --- ### Route Handler Best when you need an actual HTTP API. Example: ```text Mobile application Webhook Third-party integration Public API External frontend ``` Think: ```text Server Action = Application mutation ``` ```text Route Handler = HTTP API endpoint ``` --- # Don't Replace Every API with Server Actions Server Actions are not: > "Route Handlers are dead." Not even close. Imagine you have: ```text Next.js Web App React Native App External Partner Stripe Webhook ``` all accessing your backend. You probably need real HTTP endpoints. Server Actions are mainly fantastic when: ```text Your Next.js React UI ↓ Your Next.js server ``` are tightly integrated. --- # 10. CSRF Protection Because Server Actions are invoked over the network, request security matters. Next.js performs origin checks for Server Action requests. By default, the request's: ```text Origin ``` is compared with the application's host. This helps protect against certain **Cross-Site Request Forgery (CSRF)** attacks. --- # Allowed Origins If your application sits behind a special reverse proxy or trusted alternate domain, you may need to configure additional allowed origins. Conceptually: ```js serverActions: { allowedOrigins: [ "my-proxy.example.com" ] } ``` Don't broaden this configuration unless you actually need it. Security settings are not Pokemon. You don't need to collect every origin. 😭 --- # Request Body Size Limit Server Actions also have a request body size limit. The default is: ```text 1 MB ``` This helps prevent excessive server resource consumption. That's usually plenty for: ```text Form fields JSON-like data Normal mutations ``` If you're trying to upload: ```text 500 MB video ``` through a normal Server Action... you probably need a more appropriate file upload architecture. 😅 --- # Server Actions and File Uploads Because form actions receive: ```text FormData ``` they can receive files too. Example: ```jsx

``` Then: ```js "use server" export async function uploadAvatar( formData ) { const file = formData.get("avatar") // Validate file // Upload to storage } ``` But for large uploads, services such as: ```text S3 Cloudinary Object storage Signed upload URLs ``` are often a better architecture than sending giant files through your application server. --- # 11. Redirecting After an Action Sometimes after creating something, you want to navigate somewhere else. Example: ```text Create Post ↓ Redirect to new post ``` You can use: ```js redirect() ``` Example: ```js "use server" import { redirect } from "next/navigation" export async function createPost( formData ) { const post = await db.post.create({ data: { title: formData.get( "title" ) } }) redirect( `/posts/${post.id}` ) } ``` Now: ```text Submit ↓ Create database record ↓ Redirect ↓ /posts/123 ``` Very convenient. --- # 12. Optimistic UI Sometimes waiting for the server response makes your interface feel slow. Imagine liking a post. Without optimistic UI: ```text Click Like ↓ Wait... ↓ Server responds ↓ Heart turns red ``` With optimistic UI: ```text Click Like ↓ Heart turns red immediately ↓ Server request happens ↓ Confirm / recover if needed ``` React provides: ```js useOptimistic() ``` for these kinds of experiences. Server Actions work very well with optimistic updates. We'll keep this chapter focused on Server Actions, but remember: ```text Server Action + useOptimistic ``` can create very responsive mutation experiences. --- # A Real-World Todo Architecture Your project might look like: ```text src/ ├── actions/ │ └── todoActions.js │ ├── components/ │ ├── TodoForm.jsx │ ├── SubmitButton.jsx │ └── DeleteButton.jsx │ └── app/ └── todos/ └── page.jsx ``` --- # `todoActions.js` ```js "use server" import { revalidatePath } from "next/cache" import { auth } from "@/auth" export async function createTodo( previousState, formData ) { const session = await auth() if (!session?.user) { return { error: "Please log in." } } const title = formData.get("title") if ( typeof title !== "string" || title.trim().length === 0 ) { return { error: "Todo title is required." } } await db.todo.create({ data: { title: title.trim(), userId: session.user.id, } }) revalidatePath( "/todos" ) return { error: null, success: true, } } ``` --- # `TodoForm.jsx` ```jsx "use client" import { useActionState } from "react" import { createTodo } from "@/actions/todoActions" import { SubmitButton } from "./SubmitButton" const initialState = { error: null, success: false, } export default function TodoForm() { const [ state, formAction ] = useActionState( createTodo, initialState ) return (

{state.error && (

{state.error}

)} ) } ``` --- # `SubmitButton.jsx` ```jsx "use client" import { useFormStatus } from "react-dom" export function SubmitButton() { const { pending } = useFormStatus() return ( ) } ``` That's a pretty powerful full-stack form with surprisingly little plumbing. --- # Traditional API vs Server Action Traditional API flow: ```text Client Component ↓ onSubmit ↓ fetch() ↓ Route Handler ↓ Parse body ↓ Database ↓ JSON ↓ Client ↓ Update state ``` Server Action flow: ```text

↓ Server Action ↓ Validate + authorize ↓ Database ↓ Revalidate ↓ Updated UI ``` That doesn't make Server Actions universally better. It simply removes an entire layer when that layer isn't needed. --- # When Should You Use Server Actions? Great use cases include: - Creating records - Updating records - Deleting records - Form submissions - User profile updates - Adding items to cart - Likes - Comments - Settings - Admin operations - Login-related mutations Basically: ```text Next.js UI + Server-side mutation ``` is a strong Server Action candidate. --- # When Should You Use Route Handlers Instead? Use Route Handlers when you need: - Public APIs - Mobile app APIs - Third-party consumers - Webhooks - Explicit HTTP methods - External integrations - A separately consumed backend contract Example: ```text Stripe ↓ POST /api/webhooks/stripe ``` That's a Route Handler problem. Not a Server Action problem. --- # Common Mistake: No Validation Bad: ```js export async function createTodo( formData ) { await db.todo.create({ data: { title: formData.get("title") } }) } ``` Better: ```text Read input ↓ Validate ↓ Authenticate ↓ Authorize ↓ Mutate ``` Your database should not be the first component that discovers the user submitted nonsense. --- # Common Mistake: Trusting IDs from the Browser If the browser sends: ```text userId = 123 ``` do not automatically trust it. Get the authenticated user from your server-side session. Then compare ownership. --- # Common Mistake: Assuming `"use server"` Means Private This: ```js "use server" ``` means: ```text Execute this code on server. ``` It does NOT mean: ```text Nobody can invoke this except my button. ``` Server Functions are network-reachable. Treat them like endpoints. --- # Common Mistake: Putting Everything in One Action Avoid: ```text createUserAndUploadAvatarAndSendEmailAndGenerateReportAnd... ``` Break business operations into maintainable server-side functions. Server Actions remove API boilerplate. They don't remove software architecture. 😄 --- # Common Mistake: Using Server Actions for Reads Server Functions are particularly valuable for **mutations**. For normal page data: ```text Get products Get blog posts Get dashboard data ``` prefer fetching directly in [Server Components](/courses/nextjs) when appropriate. Don't create: ```js getPostsAction() ``` just because Server Actions exist. Use the simplest server-side data pattern. --- # Quick Reference | Need | Tool | |---|---| | Define inline Server Function | `"use server"` inside async function | | Reusable Server Functions | Top-level `"use server"` file | | Submit form | `` | | Submit with custom button | `formAction` | | Read form values | `formData.get()` | | Pending form state | `useFormStatus()` | | Action result/error state | `useActionState()` | | Manual pending action | `useTransition()` | | Refresh cached path | `revalidatePath()` | | Refresh router after action | `refresh()` | | Navigate after mutation | `redirect()` | | Optimistic UI | `useOptimistic()` | | Validate inputs | Zod or similar | | Authenticate | Server-side session check | | Authorize | Verify ownership/permissions | --- # Interview Quick Hits > **Q: What is a Server Function?** > > A Server Function is an async function marked with `"use server"` that executes on the server and can be invoked from React components. --- > **Q: What is a Server Action?** > > A Server Action is a Server Function used in an action or mutation context, such as a form submission. --- > **Q: Can a Server Function be defined inside a Client Component?** > > No. Client Components must import Server Functions from a separate module-level `"use server"` file, or receive one through props. --- > **Q: What HTTP method do Server Actions use?** > > Server Actions are invoked through `POST` requests. --- > **Q: Do Server Actions replace Route Handlers?** > > No. Server Actions are excellent for mutations originating from your Next.js application. Route Handlers remain useful for public APIs, webhooks, external clients, and explicit HTTP endpoints. --- > **Q: Are Server Actions secure automatically?** > > No. Treat every Server Action like a publicly reachable mutation endpoint. Validate inputs and perform authentication and authorization inside the action. --- > **Q: What does `useFormStatus()` do?** > > It provides information about the submission state of a parent form, including whether it is currently pending. --- > **Q: What does `useActionState()` do?** > > It connects an Action's returned state to React UI and provides the current state, an Action dispatcher, and a pending status. --- > **Q: Why does an action used with `useActionState()` receive `previousState` first?** > > Because `useActionState()` feeds the action's previous return value back into the next invocation before passing the action payload, such as FormData. --- # The Mental Model Think of traditional mutations like: ```text React ↓ Write API request ↓ Route Handler ↓ Server logic ↓ Database ``` Server Actions let Next.js simplify that to: ```text React Form ↓ Server Action ↓ Server logic ↓ Database ``` But don't forget the security layer: ```text Client request ↓ Server Action ↓ Validate ↓ Authenticate ↓ Authorize ↓ Mutate ↓ Revalidate ``` That's the real production flow. --- ## Summary Server Functions let React invoke asynchronous server-side functions without requiring you to manually build an API endpoint for every internal mutation. The key ideas are: - **Server Function** is the broader modern term - A Server Function used for a mutation is commonly called a **Server Action** - Server Functions must be async - `"use server"` marks server-side functions - Inline Server Functions can be defined inside Server Components - Client Components cannot define Server Functions inline - Client Components can import them from `"use server"` files - `` sends FormData automatically - Server Component forms support progressive enhancement - Server Actions use `POST` requests behind the scenes - `revalidatePath()` refreshes stale route data after mutations - `refresh()` can refresh the current router after a Server Action - `redirect()` can navigate after successful mutations - `useFormStatus()` provides form pending state - `useActionState()` handles returned validation and action state - `useTransition()` is useful for manually invoked actions - Server Function arguments should be treated as untrusted input - Server Actions require server-side validation - Authentication must happen inside sensitive actions - Authorization must verify ownership and permissions - Server Actions do not replace Route Handlers - The default Server Action request body limit is 1 MB - Next.js performs origin checks to help protect Server Actions against CSRF The biggest rule is: ```text Server Action ≠ Trusted Function ``` Think: ```text Server Action = Convenient network-accessible server mutation ``` Once that clicks, Server Actions stop feeling like magic and start feeling like what they really are: a cleaner bridge between your React UI and your server logic. And that's how we'll keep learning Next.js on **asif.to** — remove boilerplate where the framework can safely handle it, but never remove the important parts like validation, authentication, and authorization. Less `fetch()` gymnastics, more actual building. 🚀