mirror of
https://github.com/hanzoai/next.js.git
synced 2026-10-30 14:46:38 +00:00
c2b4c0815c
This PRs unifies the caching story across the docs, making Cache Components the happy path, while still providing guidance to users in the old model. However, instead of explaining the old model and its caching layers, we've created a new guide focusing on what APIs to use and when. This follow-up PR aligns terminology across the docs: https://github.com/vercel/next.js/pull/90589 ## IA updates Getting Started section: - Improves Getting Started progression: - **Before:** CC → Fetching Data → Updating Data → Caching and Revalidating (old and new model mixed) - **After:** Fetching Data (Dynamic) → Mutating Data (Dynamic) → Caching with CC (Prerendering) → Revalidating with CC. - New: `caching.mdx` (CC-first) - Structure: - Enabling Cache Components - Data vs UI-level caching - Working with request time APIs - Passing request values to cached functions - Working with non-deterministic operations - Working with synchronous operations - How rendering works (PPR and static shell story) - New: `revalidating.mdx` (CC-first) - Explains how to use `cacheLife` and `cacheTag` Guides Section: - New: `caching-and-revalidating.mdx` (Previous Model) - For users who are not using CC, includes `fetch` options and route segment config - Moves route segment config options that don't apply to CC from API reference to this guide (for easy archiving in the future). - New: `migrating-to-cache-components.mdx` (WIP) - Del: `caching.mdx` 😌 ## Terminology We should remove caching layers from the docs. Users only needed to be exposed to them when they were configured independently, but the new CC APIs work across layers. To make it easier to review this PR, I'm consolidating terminology and fixing broken links in a new PR: https://github.com/vercel/next.js/pull/90589 --------- Co-authored-by: Vercel <vercel[bot]@users.noreply.github.com> Co-authored-by: Joseph <[email protected]>
108 lines
3.6 KiB
Plaintext
108 lines
3.6 KiB
Plaintext
---
|
|
title: Forms and Mutations
|
|
nav_title: Forms and Mutations
|
|
description: Learn how to handle form submissions and data mutations with Next.js.
|
|
---
|
|
|
|
Forms enable you to create and update data in web applications. Next.js provides a powerful way to handle form submissions and data mutations using **API Routes**.
|
|
|
|
> **Good to know:**
|
|
>
|
|
> - We will soon recommend [incrementally adopting](/docs/app/guides/migrating/app-router-migration) the App Router and using [Server Actions](/docs/app/getting-started/mutating-data) for handling form submissions and data mutations. Server Actions allow you to define asynchronous server functions that can be called directly from your components, without needing to manually create an API Route.
|
|
> - API Routes [do not specify CORS headers](https://developer.mozilla.org/docs/Web/HTTP/CORS), meaning they are same-origin only by default.
|
|
> - Since API Routes run on the server, we're able to use sensitive values (like API keys) through [Environment Variables](/docs/pages/guides/environment-variables) without exposing them to the client. This is critical for the security of your application.
|
|
|
|
## Examples
|
|
|
|
### Redirecting
|
|
|
|
If you would like to redirect the user to a different route after a mutation, you can [`redirect`](/docs/pages/building-your-application/routing/api-routes#response-helpers) to any absolute or relative URL:
|
|
|
|
```ts filename="pages/api/submit.ts" switcher
|
|
import type { NextApiRequest, NextApiResponse } from 'next'
|
|
|
|
export default async function handler(
|
|
req: NextApiRequest,
|
|
res: NextApiResponse
|
|
) {
|
|
const id = await addPost()
|
|
res.redirect(307, `/post/${id}`)
|
|
}
|
|
```
|
|
|
|
```js filename="pages/api/submit.js" switcher
|
|
export default async function handler(req, res) {
|
|
const id = await addPost()
|
|
res.redirect(307, `/post/${id}`)
|
|
}
|
|
```
|
|
|
|
### Setting cookies
|
|
|
|
You can set cookies inside an API Route using the `setHeader` method on the response:
|
|
|
|
```ts filename="pages/api/cookie.ts" switcher
|
|
import type { NextApiRequest, NextApiResponse } from 'next'
|
|
|
|
export default async function handler(
|
|
req: NextApiRequest,
|
|
res: NextApiResponse
|
|
) {
|
|
res.setHeader('Set-Cookie', 'username=lee; Path=/; HttpOnly')
|
|
res.status(200).send('Cookie has been set.')
|
|
}
|
|
```
|
|
|
|
```js filename="pages/api/cookie.js" switcher
|
|
export default async function handler(req, res) {
|
|
res.setHeader('Set-Cookie', 'username=lee; Path=/; HttpOnly')
|
|
res.status(200).send('Cookie has been set.')
|
|
}
|
|
```
|
|
|
|
### Reading cookies
|
|
|
|
You can read cookies inside an API Route using the [`cookies`](/docs/pages/building-your-application/routing/api-routes#request-helpers) request helper:
|
|
|
|
```ts filename="pages/api/cookie.ts" switcher
|
|
import type { NextApiRequest, NextApiResponse } from 'next'
|
|
|
|
export default async function handler(
|
|
req: NextApiRequest,
|
|
res: NextApiResponse
|
|
) {
|
|
const auth = req.cookies.authorization
|
|
// ...
|
|
}
|
|
```
|
|
|
|
```js filename="pages/api/cookie.js" switcher
|
|
export default async function handler(req, res) {
|
|
const auth = req.cookies.authorization
|
|
// ...
|
|
}
|
|
```
|
|
|
|
### Deleting cookies
|
|
|
|
You can delete cookies inside an API Route using the `setHeader` method on the response:
|
|
|
|
```ts filename="pages/api/cookie.ts" switcher
|
|
import type { NextApiRequest, NextApiResponse } from 'next'
|
|
|
|
export default async function handler(
|
|
req: NextApiRequest,
|
|
res: NextApiResponse
|
|
) {
|
|
res.setHeader('Set-Cookie', 'username=; Path=/; HttpOnly; Max-Age=0')
|
|
res.status(200).send('Cookie has been deleted.')
|
|
}
|
|
```
|
|
|
|
```js filename="pages/api/cookie.js" switcher
|
|
export default async function handler(req, res) {
|
|
res.setHeader('Set-Cookie', 'username=; Path=/; HttpOnly; Max-Age=0')
|
|
res.status(200).send('Cookie has been deleted.')
|
|
}
|
|
```
|