docs: Rewrite Rendering Section and React Essentials Page (#51579)

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: vercel/front#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>

docs/02-app/01-building-your-application/01-routing/02-pages-and-layouts.mdx

@@ -54,7 +54,7 @@ export default function Page() {
 > - A page is always the [leaf](/docs/app/building-your-application/routing#terminology) of the [route subtree](/docs/app/building-your-application/routing#terminology).
 > - `.js`, `.jsx`, or `.tsx` file extensions can be used for Pages.
 > - A `page.js` file is required to make a route segment publicly accessible.
-> - Pages are [Server Components](/docs/getting-started/react-essentials) by default but can be set to a [Client Component](/docs/getting-started/react-essentials#client-components).
+> - Pages are [Server Components](/docs/app/building-your-application/rendering/server-components) by default but can be set to a [Client Component](/docs/app/building-your-application/rendering/client-components).
 > - Pages can fetch data. View the [Data Fetching](/docs/app/building-your-application/data-fetching) section for more information.
 
 ## Layouts
@@ -109,7 +109,7 @@ export default function DashboardLayout({
 > - Any route segment can optionally define its own [Layout](#nesting-layouts). These layouts will be shared across all pages in that segment.
 > - Layouts in a route are **nested** by default. Each parent layout wraps child layouts below it using the React `children` prop.
 > - You can use [Route Groups](/docs/app/building-your-application/routing/route-groups) to opt specific route segments in and out of shared layouts.
-> - Layouts are [Server Components](/docs/getting-started/react-essentials) by default but can be set to a [Client Component](/docs/getting-started/react-essentials#client-components).
+> - Layouts are [Server Components](/docs/app/building-your-application/rendering/server-components) by default but can be set to a [Client Component](/docs/app/building-your-application/rendering/client-components).
 > - Layouts can fetch data. View the [Data Fetching](/docs/app/building-your-application/data-fetching) section for more information.
 > - Passing data between a parent layout and its children is not possible. However, you can fetch the same data in a route more than once, and React will [automatically dedupe the requests](/docs/app/building-your-application/caching#request-memoization) without affecting performance.
 > - Layouts do not have access to the current route segment(s). To access route segments, you can use [`useSelectedLayoutSegment`](/docs/app/api-reference/functions/use-selected-layout-segment) or [`useSelectedLayoutSegments`](/docs/app/api-reference/functions/use-selected-layout-segments) in a Client Component.
@@ -150,7 +150,7 @@ export default function RootLayout({ children }) {
 > - The root layout must define `<html>` and `<body>` tags since Next.js does not automatically create them.
 > - You can use the [built-in SEO support](/docs/app/building-your-application/optimizing/metadata) to manage `<head>` HTML elements, for example, the `<title>` element.
 > - You can use [route groups](/docs/app/building-your-application/routing/route-groups) to create multiple root layouts. See an [example here](/docs/app/building-your-application/routing/route-groups#creating-multiple-root-layouts).
-> - The root layout is a [Server Component](/docs/getting-started/react-essentials) by default and **can not** be set to a [Client Component](/docs/getting-started/react-essentials#client-components).
+> - The root layout is a [Server Component](/docs/app/building-your-application/rendering/server-components) by default and **can not** be set to a [Client Component](/docs/app/building-your-application/rendering/client-components).
 
 > **Migrating from the `pages` directory:** The root layout replaces the [`_app.js`](/docs/pages/building-your-application/routing/custom-app) and [`_document.js`](/docs/pages/building-your-application/routing/custom-document) files. [View the migration guide](/docs/app/building-your-application/upgrading/app-router-migration#migrating-_documentjs-and-_appjs).
 

docs/02-app/01-building-your-application/01-routing/03-linking-and-navigating.mdx

@@ -165,8 +165,8 @@ There are two ways routes are prefetched in Next.js:
 
 The`<Link>`'s prefetching behavior is different for static and dynamic routes:
 
-- [**Static Routes**](/docs/app/building-your-application/rendering/static-and-dynamic#static-rendering-default): `prefetch` defaults to `true`. The entire route is prefetched and cached.
-- [**Dynamic Routes**](/docs/app/building-your-application/rendering/static-and-dynamic#dynamic-rendering): `prefetch` default to automatic. Only the shared layout down until the first `loading.js` file is prefetched and cached for `30s`. This reduces the cost of fetching an entire dynamic route, and it means you can show an [instant loading state](/docs/app/building-your-application/routing/loading-ui-and-streaming#instant-loading-states) for better visual feedback to users.
+- [**Static Routes**](/docs/app/building-your-application/rendering/server-components#static-rendering-default): `prefetch` defaults to `true`. The entire route is prefetched and cached.
+- [**Dynamic Routes**](/docs/app/building-your-application/rendering/server-components#dynamic-rendering): `prefetch` default to automatic. Only the shared layout down until the first `loading.js` file is prefetched and cached for `30s`. This reduces the cost of fetching an entire dynamic route, and it means you can show an [instant loading state](/docs/app/building-your-application/routing/loading-ui-and-streaming#instant-loading-states) for better visual feedback to users.
 
 You can disable prefetching by setting the `prefetch` prop to `false`.
 

docs/02-app/01-building-your-application/01-routing/05-dynamic-routes.mdx

@@ -45,7 +45,7 @@ See the [generateStaticParams()](#generating-static-params) page to learn how to
 
 ## Generating Static Params
 
-The `generateStaticParams` function can be used in combination with [dynamic route segments](/docs/app/building-your-application/routing/dynamic-routes) to [**statically generate**](/docs/app/building-your-application/rendering/static-and-dynamic#static-rendering-default) routes at build time instead of on-demand at request time.
+The `generateStaticParams` function can be used in combination with [dynamic route segments](/docs/app/building-your-application/routing/dynamic-routes) to [**statically generate**](/docs/app/building-your-application/rendering/server-components#static-rendering-default) routes at build time instead of on-demand at request time.
 
 ```tsx filename="app/blog/[slug]/page.tsx" switcher
 export async function generateStaticParams() {

docs/02-app/01-building-your-application/01-routing/13-internationalization.mdx

@@ -127,7 +127,7 @@ export default async function Page({ params: { lang } }) {
 }
 ```
 
-Because all layouts and pages in the `app/` directory default to [Server Components](/docs/getting-started/react-essentials#server-components), we do not need to worry about the size of the translation files affecting our client-side JavaScript bundle size. This code will **only run on the server**, and only the resulting HTML will be sent to the browser.
+Because all layouts and pages in the `app/` directory default to [Server Components](/docs/app/building-your-application/rendering/server-components), we do not need to worry about the size of the translation files affecting our client-side JavaScript bundle size. This code will **only run on the server**, and only the resulting HTML will be sent to the browser.
 
 ## Static Generation
 

docs/02-app/01-building-your-application/01-routing/index.mdx

@@ -36,7 +36,7 @@ First, you will see these terms being used throughout the documentation. Here's
 
 ## The `app` Router
 
-In version 13, Next.js introduced a new **App Router** built on [React Server Components](/docs/getting-started/react-essentials#server-components), which supports shared layouts, nested routing, loading states, error handling, and more.
+In version 13, Next.js introduced a new **App Router** built on [React Server Components](/docs/app/building-your-application/rendering/server-components), which supports shared layouts, nested routing, loading states, error handling, and more.
 
 The App Router works in a new directory named `app`. The `app` directory works alongside the `pages` directory to allow for incremental adoption. This allows you to opt some routes of your application into the new behavior while keeping other routes in the `pages` directory for previous behavior. If your application uses the `pages` directory, please also see the [Pages Router](/docs/pages/building-your-application/routing) documentation.
 
@@ -50,9 +50,9 @@ The App Router works in a new directory named `app`. The `app` directory works a
   height="444"
 />
 
-By default, components inside `app` are [React Server Components](/docs/getting-started/react-essentials#server-components). This is a performance optimization and allows you to easily adopt them, and you can also use [Client Components](/docs/getting-started/react-essentials#client-components).
+By default, components inside `app` are [React Server Components](/docs/app/building-your-application/rendering/server-components). This is a performance optimization and allows you to easily adopt them, and you can also use [Client Components](/docs/app/building-your-application/rendering/client-components).
 
-> **Recommendation:** Check out the [Server and Client Components](/docs/getting-started/react-essentials) page if you're new to Server Components.
+> **Recommendation:** Check out the [Server](/docs/app/building-your-application/rendering/server-components) page if you're new to Server Components.
 
 ## Roles of Folders and Files
 

docs/02-app/01-building-your-application/02-data-fetching/01-fetching-caching-and-revalidating.mdx

@@ -277,7 +277,7 @@ There's an extensive list of Segment Config options, giving you fine-grained con
 
 In cases where you're using a third-party library that doesn't support or expose `fetch` (for example, a database, CMS, or ORM client), you can configure the caching and revalidating behavior of those requests using the [Route Segment Config Option](/docs/app/api-reference/file-conventions/route-segment-config) and React's `cache` function.
 
-Whether the data is cached or not will depend on whether the route segment is [statically or dynamically rendered](/docs/app/building-your-application/rendering/static-and-dynamic). If the segment is static (default), the output of the request will be cached and revalidated as part of the route segment. If the segment is dynamic, the output of the request will _not_ be cached and will be re-fetched on every request when the segment is rendered.
+Whether the data is cached or not will depend on whether the route segment is [statically or dynamically rendered](/docs/app/building-your-application/rendering/server-components#server-rendering-strategies). If the segment is static (default), the output of the request will be cached and revalidated as part of the route segment. If the segment is dynamic, the output of the request will _not_ be cached and will be re-fetched on every request when the segment is rendered.
 
 > **Good to know:**
 >

docs/02-app/01-building-your-application/02-data-fetching/02-patterns.mdx

@@ -304,10 +304,10 @@ export const getItem = cache(async (id) => {
 })
 ```
 
-With this approach, you can eagerly fetch data, cache responses, and guarantee that this data fetching [only happens on the server](/docs/getting-started/react-essentials#keeping-server-only-code-out-of-client-components-poisoning).
+With this approach, you can eagerly fetch data, cache responses, and guarantee that this data fetching [only happens on the server](/docs/app/building-your-application/rendering/composition-patterns#keeping-server-only-code-out-of-the-client-environment).
 
 The `utils/get-item` exports can be used by Layouts, Pages, or other components to give them control over when an item's data is fetched.
 
 > **Good to know:**
 >
-> - We recommend using the [`server-only` package](/docs/getting-started/react-essentials#keeping-server-only-code-out-of-client-components-poisoning) to make sure server data fetching functions are never used on the client.
+> - We recommend using the [`server-only` package](/docs/app/building-your-application/rendering/composition-patterns#keeping-server-only-code-out-of-the-client-environment) to make sure server data fetching functions are never used on the client.

docs/02-app/01-building-your-application/02-data-fetching/03-server-actions.mdx

@@ -61,7 +61,7 @@ export default function AddToCart({ productId }) {
 
 Rather than needing to manually create an API endpoint, Server Actions automatically create an endpoint for Next.js to use behind the scenes. When calling a Server Action, Next.js sends a `POST` request to the page you're on with metadata for which action to run.
 
-Server Actions inherit the same runtime (either [Node.js or Edge](/docs/app/building-your-application/rendering/edge-and-nodejs-runtimes)) defined by the `page` or `layout` they're used on. Currently, if a route uses a Server Action, it is required to [render dynamically](/docs/app/building-your-application/rendering/static-and-dynamic).
+Server Actions inherit the same runtime (either [Node.js or Edge](/docs/app/building-your-application/rendering/edge-and-nodejs-runtimes)) defined by the `page` or `layout` they're used on. Currently, if a route uses a Server Action, it is required to [render dynamically](/docs/app/building-your-application/rendering/server-components#server-rendering-strategies).
 
 > **Good to know:**
 >