### What?
Clarify the "Forms and Mutations" docs.
### Why?
This may be opinionated, but I believe this section of the docs starts out assuming that the user knows how the `<form>` HTML works. Coming from the client side React world, most developers are used to using state in forms. Clarifying that this data is accessible via the standard web API [FormData](https://developer.mozilla.org/en-US/docs/Web/API/FormData/FormData) is essential for both transitioning developers and new developers.
### What?
This adds to the docs a guide for migrating a Vite application to
Next.js. It also contains a section that lists the reasons why one would
want to switch from Vite to Next.js.
### Why?
This guide is helpful for developers that want to switch to Next.js but
don't know how difficult that would be and how to do it. The "Why?" list
is also helpful to developers who haven't yet been convinced to switch
or need help formulating the reasons to switch to decision-makers.
This guide was [first published on the Inngest
blog](https://www.inngest.com/blog/migrating-from-vite-to-nextjs). To
our own surprise, we were able to [migrate from Vite to
Next.js](https://github.com/inngest/inngest/pull/479) our [Dev Server
app](https://github.com/inngest/inngest/tree/main#the-inngest-dev-server)
in less than a day, which motivated us to share our learnings with the
community.
### How?
The guide aims to have the minimum number of steps to get a working
Next.js application so that
the reader can then adopt Next.js features incrementally. This means the
migration of the router isn't part of this guide. However, this would be
something valuable to document at a later time so that the reader can
also learn how to migrate to the App Router and get all the Next.js
benefits.
## What?
- Updated the heading structure in the documentation to maintain a consistent hierarchy.
- All primary points now use `###` for better readability and understanding of content structure.
## Why?
While reviewing the documentation, I noticed that the heading levels were inconsistent between sections 1, 2, and 3-5.
for internal:
https://vercel.slack.com/archives/C03S8ED1DKM/p1691700057242999
### Problem
- The existing [`redirect()`
function](https://nextjs.org/docs/app/api-reference/functions/redirect)
can't control the status code.
- The existing [`redirect()`
function](https://nextjs.org/docs/app/api-reference/functions/redirect)
returns a 307 HTTP redirect response while it returns a 308-equivalent
meta tag `<meta http-equiv="refresh" content="0;url=/foo"/>` in
streaming response (e.g., suspense boundary), making the behavior
inconsistent.
### Solution
Adding a new `permanentRedirect()` function and changing the meta tag
default accordingly.
| func | HTTP status | meta tag |
|---|:---:|---|
| `redirect()` | 307 | `<meta http-equiv="refresh"
content="1;url=/foo"/>` |
| `permanentRedirect()` | 308 | `<meta http-equiv="refresh"
content="0;url=/foo"/>` |
ref.
https://developers.google.com/search/docs/crawling-indexing/301-redirects
---------
Co-authored-by: JJ Kasper <jj@jjsweb.site>
Co-authored-by: Tim Neutkens <tim@timneutkens.nl>
Co-authored-by: kodiakhq[bot] <49736102+kodiakhq[bot]@users.noreply.github.com>
add if statement, because typescript throws error: revalidatePath require `string`, but `searchParams.get('path')` returns `string|null` type
Co-authored-by: JJ Kasper <22380829+ijjk@users.noreply.github.com>
https://nextjs.org/docs/app/building-your-application/data-fetching/forms-and-mutations
Some of the code blocks where I only specified TS code snippets aren't
working with JS as well (when there are no types). I think I might have
incorrectly assumed you could leave those out. So added the JS snippets
in here (same code, just different file names).
This PR is a larger change to documentation to make the following
updates:
- Deconstructs [Server
Actions](https://nextjs.org/docs/app/building-your-application/data-fetching/server-actions)
into "Forms and Mutations" and an API reference
- Removes content in place of future React API documentation pages
- Removes outdated [Building
Forms](https://nextjs.org/docs/pages/building-your-application/data-fetching/building-forms)
docs from the Pages Router and adds conditional content for both routes
in "Forms and Mutations"
- Adds TypeScript code blocks to API Routes page, recommends Route
Handlers for isomorphic signatures.
- Updates `revalidatePath` and `revalidateTag` docs to have a Server
Actions example.
---------
Co-authored-by: Delba de Oliveira <32464864+delbaoliveira@users.noreply.github.com>
Hello!
I recently tried to cache the `.next/cache` directory in a GitHub action following what was said in the documentation and realized that hashing the source files didn't work properly.
This problem also occured in [next-cache](https://github.com/jongwooo/next-cache) and was fixed by [this PR](https://github.com/jongwooo/next-cache/pull/17).
This PR simply changes the example from the documentation to apply the same fix (stop using brackets in the patterns passed to `hashFiles`).
Hope it helps!
### Improving Documentation
- [x] Run `pnpm prettier-fix` to fix formatting issues before opening the PR.
- [x] Read the Docs Contribution Guide to ensure your contribution follows the docs guidelines: https://nextjs.org/docs/community/contribution-guide
This PR adds missing parameters to the `useSelectedLayoutSegment` & `useSelectedLayoutSegments` hooks since they take *optional* `parallelRoutesKey`.
Co-authored-by: Lee Robinson <9113740+leerob@users.noreply.github.com>
We initially wrote the [React
page](https://nextjs.org/docs/getting-started/react-essentials) to
introduce Server Components in the App Router, but over time, some
implementation details have changed, and the information has become
stale. The React team is working on adding new docs, so I'd like to
change the narrative on the Next.js docs from "client vs. server
components" to "writing code for the server and for the client" - and
link back to the React documentation when it becomes available.
As React developers, we're very familiar with writing code for the
client, it's nice and simple. But doing so comes at the expense of not
being familiar with the server. The aim of these docs is to help
developers become proficient in both the client and server environments.
I'd like to take it back to the foundations, and not use abstractions
like SSG and CSR, MPAs or SPAs, as those terms come with their own set
of assumptions that make it harder to understand how RSC works. Instead,
we'll focus on the request lifecycle, show how application code flows
from the server to the client, and discuss the trade-offs of doing
operations in each environment.
- [x] Page: Rendering Fundamentals
- [x] Environments: Client and Server
- [x] Request-response lifecycle
- [x] Network Boundary
- [x] Page: Server Components
- [x] Benefits and use cases of server rendering
- [x] How to use Server Components in Next.js
- [x] How Server Components are rendered
- [x] Static Rendering
- [x] Dynamic Rendering
- [x] Streaming
- [x] Page: Client Components
- [x] Benefits and use cases of client rendering
- [x] How to use Client Components in Next.js
- [x] How Client Components are rendered
- [x] Initial vs. Subsquent navigation
- [x] Page: Composition Patterns
- [x] When to use client and server components
- [x] Server Component Patterns
- [x] Client Component Patterns
- [x] Interleaving Client and Server Components
- [ ] ~Diagrams~ will follow up with new PR.
- [x] Set up redirects: https://github.com/vercel/front/pull/24917
---------
Co-authored-by: Térence Hollander <hollanderterence@gmail.com>
Co-authored-by: shawnthwei <32075290+shawnthwei@users.noreply.github.com>
Co-authored-by: Michael Novotny <manovotny@gmail.com>
Fixed `next/jest.js` import in documentation. without `.js` it show this error
```
Error [ERR_MODULE_NOT_FOUND]: Cannot find module 'F:\React\my-project\node_modules\next\jest' imported from F:\React\my-project\jest.config.mjs
Did you mean to import next/jest.js?
at new NodeError (node:internal/errors:399:5)
at finalizeResolution (node:internal/modules/esm/resolve:326:11)
at moduleResolve (node:internal/modules/esm/resolve:945:10)
at defaultResolve (node:internal/modules/esm/resolve:1153:11)
at nextResolve (node:internal/modules/esm/loader:163:28)
at ESMLoader.resolve (node:internal/modules/esm/loader:838:30)
at ESMLoader.getModuleJob (node:internal/modules/esm/loader:424:18)
at ModuleWrap.<anonymous> (node:internal/modules/esm/module_job:77:40)
at link (node:internal/modules/esm/module_job:76:36)
```
### Why?
Many developers are asking how to add internationalized routing in the App Router as it works in the Pages Router. [next-i18n-router](https://www.npmjs.com/package/next-i18n-router) is a very helpful package that fully solves this challenge.
### How?
Unlike the example provided in these Next.js i18n docs, [next-i18n-router](https://www.npmjs.com/package/next-i18n-router) does not require nesting all pages in a `[lang]` dynamic segment. It also allows for the default language to be accessible without a locale prefix in the path (just like in the Pages Router).
It includes locale detection based on the `accept-language` header as recommended in the Next.js docs, as well as support for the `NEXT_LOCALE` cookie to set a user's preferred language (just like in the Pages Router).
Clarify what status code is returned when streaming, and in relation to `redirect` and `not-found`.
Relates to: https://github.com/vercel/next.js/pull/54361
Co-authored-by: Lee Robinson <9113740+leerob@users.noreply.github.com>
Fixes: https://vercel.slack.com/archives/C03S9JCH2Q5/p1692619927373449
- Updates wording on nesting, to say it's not the actual output, but rather how `template.js` nests between `layout.js` and its children.
- Remove mention of animations, needs further clarification.
Hello,
I just make this PR because the `/me.png` example is not in "remote images" section but in "local images", that's why I propose to edit this :)
Thank you!
### Improving Documentation
- [x] Run `pnpm prettier-fix` to fix formatting issues before opening the PR.
- [x] Read the Docs Contribution Guide to ensure your contribution follows the docs guidelines: https://nextjs.org/docs/community/contribution-guide
Partial fix for #54012: do not generate a blur image in the image loader when the image is detected to be animated, rather than returning the *entire* animated image as the blur image.
When implementing `opengraph-image` in my [personal-site-project](https://github.com/kylemcd/personal-site). I was consistently running into issues where custom fonts would either only work locally or only work on vercel. To me it seemed like differences in pathing in `edge` vs `nodejs` runtimes. After digging around I found issue #48081, more specifically [this comment](https://github.com/vercel/next.js/issues/48081#issuecomment-1565842740) where moving the `fetch` for the font into the `Image` function solved the issue.
I'm not sure if this is 100% the correct fix, or if this is an issue that needs to be solved in another way. If that's not the case this PR updates the documentation around `opengraph-image` to have the fetch for custom fonts inside of the `Image` function.
Added a switcher on a code snippet under heading -> `Using Cookies`, just like the other code snippets on this page got one..
(For those who don't know what a switcher is -> It's just a simple functionality for changing `typescript` code to `javascript` and vice-versa, kind of a UI feature for better experience`
Co-authored-by: Balázs Orbán <18369201+balazsorban44@users.noreply.github.com>
Previous of after (before in linked issue)
```
❯ pnpm add --save-dev @next/eslint-plugin-next
Already up to date
Progress: resolved 525, reused 517, downloaded 0, added 0, done
Done in 6.4s
```
Resolves#53937
