vercel · leerob · Jun 13, 2023 · Jun 10, 2023 · Jun 10, 2023 · Jun 10, 2023
@@ -39,7 +39,7 @@ Next.js now ships with TypeScript, ESLint, and Tailwind CSS configuration by def
 
 After the prompts, `create-next-app` will create a folder with your project name and install the required dependencies.
 
-> **Note:** While you can use the [Pages Router](/docs/pages) in your new project. We recommend starting new applications with the App Router to leverage React's latest features.
+> **Good to know**: While you can use the [Pages Router](/docs/pages) in your new project. We recommend starting new applications with the App Router to leverage React's latest features.
 
 ## Manual Installation
 

@@ -99,7 +99,7 @@ export default function Counter() {
 
 Since Server Components are the default, all components are part of the Server Component module graph unless defined or imported in a module that starts with the `"use client"` directive.
 
-> **Good to know:**
+> **Good to know**:
 >
 > - Components in the Server Component module graph are guaranteed to be only rendered on the server.
 > - Components in the Client Component module graph are primarily rendered on the client, but with Next.js, they can also be pre-rendered on the server and hydrated on the client.
@@ -186,7 +186,7 @@ Behind the scenes, React handles rendering as follows:
 - On the client, React renders Client Components and _slots in_ the rendered result of Server Components, merging the work done on the server and client.
   - If any Server Components are nested inside a Client Component, their rendered content will be placed correctly within the Client Component.
 
-> **Good to know:** In Next.js, during the initial page load, both the rendered result of Server Components from the above step and Client Components are [pre-rendered on the server as HTML](/docs/app/building-your-application/rendering#static-and-dynamic-rendering-on-the-server) to produce a faster initial page load.
+> **Good to know**: In Next.js, during the initial page load, both the rendered result of Server Components from the above step and Client Components are [pre-rendered on the server as HTML](/docs/app/building-your-application/rendering#static-and-dynamic-rendering-on-the-server) to produce a faster initial page load.
 
 ### Nesting Server Components inside Client Components
 
@@ -731,7 +731,7 @@ export default function RootLayout({ children }) {
 
 With the provider rendered at the root, all other Client Components throughout your app will be able to consume this context.
 
-> Note: You should render providers as deep as possible in the tree – notice how `ThemeProvider` only wraps `{children}` instead of the entire `<html>` document. This makes it easier for Next.js to optimize the static parts of your Server Components.
+> **Good to know**: You should render providers as deep as possible in the tree – notice how `ThemeProvider` only wraps `{children}` instead of the entire `<html>` document. This makes it easier for Next.js to optimize the static parts of your Server Components.
 
 ### Rendering third-party context providers in Server Components
 

@@ -37,7 +37,7 @@ A special [`page.js` file](/docs/app/building-your-application/routing/pages-and
 
 In this example, the `/dashboard/analytics` URL path is _not_ publicly accessible because it does not have a corresponding `page.js` file. This folder could be used to store components, stylesheets, images, or other colocated files.
 
-> **Good to know:** `.js`, `.jsx`, or `.tsx` file extensions can be used for special files.
+> **Good to know**: `.js`, `.jsx`, or `.tsx` file extensions can be used for special files.
 
 ## Creating UI
 

@@ -49,7 +49,7 @@ export default function Page() {
 }
 ```
 
-> **Good to know:**
+> **Good to know**:
 >
 > - 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.
@@ -103,7 +103,7 @@ export default function DashboardLayout({
 }
 ```
 
-> **Good to know:**
+> **Good to know**:
 >
 > - The top-most layout is called the [Root Layout](#root-layout-required). This **required** layout is shared across all pages in an application. Root layouts must contain `html` and `body` tags.
 > - Any route segment can optionally define its own [Layout](#nesting-layouts). These layouts will be shared across all pages in that segment.
@@ -144,7 +144,7 @@ export default function RootLayout({ children }) {
 }
 ```
 
-> **Good to know:**
+> **Good to know**:
 >
 > - The `app` directory **must** include a root layout.
 > - The root layout must define `<html>` and `<body>` tags since Next.js does not automatically create them.
@@ -267,6 +267,6 @@ export default function Page() {
 }
 ```
 
-> **Good to know:** You should **not** manually add `<head>` tags such as `<title>` and `<meta>` to root layouts. Instead, you should use the [Metadata API](/docs/app/api-reference/functions/generate-metadata) which automatically handles advanced requirements such as streaming and de-duplicating `<head>` elements.
+> **Good to know**: You should **not** manually add `<head>` tags such as `<title>` and `<meta>` to root layouts. Instead, you should use the [Metadata API](/docs/app/api-reference/functions/generate-metadata) which automatically handles advanced requirements such as streaming and de-duplicating `<head>` elements.
 
 [Learn more about available metadata options in the API reference.](/docs/app/api-reference/functions/generate-metadata)
@@ -140,7 +140,7 @@ The `useRouter` provides methods such as `push()`, `refresh()`, and more. See th
 
 ### Client-side Caching of Rendered Server Components
 
-> **Good to know:** This client-side cache is different from the server-side [Next.js HTTP cache](/docs/app/building-your-application/data-fetching#caching-data).
+> **Good to know**: This client-side cache is different from the server-side [Next.js HTTP cache](/docs/app/building-your-application/data-fetching#caching-data).
 
 The new router has an **in-memory client-side cache** that stores the **rendered result** of Server Components (payload). The cache is split by route segments which allows invalidation at any level and ensures consistency across concurrent renders.
 
@@ -163,7 +163,7 @@ By default, routes are prefetched as they become visible in the viewport when us
 - If the route is static, all the Server Component payloads for the route segments will be prefetched.
 - If the route is dynamic, the payload from the first shared layout down until the first `loading.js` file is prefetched. This reduces the cost of prefetching the whole route dynamically and allows [instant loading states](/docs/app/building-your-application/routing/loading-ui-and-streaming#instant-loading-states) for dynamic routes.
 
-> **Good to know:**
+> **Good to know**:
 >
 > - Prefetching is only enabled in production.
 > - Prefetching can be disabled by passing `prefetch={false}` to `<Link>`.

@@ -70,7 +70,7 @@ In the example above, both `(marketing)` and `(shop)` have their own root layout
 
 ---
 
-> **Good to know:**
+> **Good to know**:
 >
 > - The naming of route groups has no special significance other than for organization. They do not affect the URL path.
 > - Routes that include a route group **should not** resolve to the same URL path as other routes. For example, since route groups don't affect URL structure, `(marketing)/about/page.js` and `(shop)/about/page.js` would both resolve to `/about` and cause an error.

@@ -35,7 +35,7 @@ export default function Page({ params }) {
 
 See the [generateStaticParams()](#generating-static-params) page to learn how to generate the params for the segment.
 
-> **Note:** Dynamic Segments are equivalent to [Dynamic Routes](/docs/app/building-your-application/routing/dynamic-routes) in the `pages` directory.
+> **Good to know**: Dynamic Segments are equivalent to [Dynamic Routes](/docs/app/building-your-application/routing/dynamic-routes) in the `pages` directory.
 
 ## Generating Static Params
 
@@ -116,4 +116,4 @@ export default function Page({ params }) {
 | `app/shop/[...slug]/page.js`        | `{ slug: string[] }`                     |
 | `app/[categoryId]/[itemId]/page.js` | `{ categoryId: string, itemId: string }` |
 
-> **Note**: This may be done automatically by the [TypeScript plugin](/docs/app/building-your-application/configuring/typescript#typescript-plugin) in the future.
+> **Good to know**: This may be done automatically by the [TypeScript plugin](/docs/app/building-your-application/configuring/typescript#typescript-plugin) in the future.
@@ -51,7 +51,7 @@ In the same folder, `loading.js` will be nested inside `layout.js`. It will auto
   height="768"
 />
 
-> **Good to know:**
+> **Good to know**:
 >
 > - Navigation is immediate, even with [server-centric routing](/docs/app/building-your-application/routing#server-centric-routing-with-client-side-navigation).
 > - Navigation is interruptible, meaning changing routes does not need to wait for the content of the route to fully load before navigating to another route.

@@ -18,7 +18,7 @@ Route Handlers allow you to create custom request handlers for a given route usi
   height="444"
 />
 
-> **Good to know:** Route Handlers are only available inside the `app` directory. They are the equivalent of [API Routes](/docs/pages/building-your-application/routing/api-routes) inside the `pages` directory meaning you **do not** need to use API Routes and Route Handlers together.
+> **Good to know**: Route Handlers are only available inside the `app` directory. They are the equivalent of [API Routes](/docs/pages/building-your-application/routing/api-routes) inside the `pages` directory meaning you **do not** need to use API Routes and Route Handlers together.
 
 ## Convention
 
@@ -170,7 +170,7 @@ export async function POST() {
 }
 ```
 
-> **Note:** Previously, API Routes could have been used for use cases like handling form submissions. Route Handlers are likely not the solution for these uses cases. We will be recommending the use of [mutations](/docs/app/building-your-application/data-fetching/server-actions) for this when ready.
+> **Good to know**: Previously, API Routes could have been used for use cases like handling form submissions. Route Handlers are likely not the solution for these uses cases. We will be recommending the use of [mutations](/docs/app/building-your-application/data-fetching/server-actions) for this when ready.
 
 ### Route Resolution
 

@@ -81,7 +81,7 @@ export const config = {
 }
 ```
 
-> **Note**: The `matcher` values need to be constants so they can be statically analyzed at build-time. Dynamic values such as variables will be ignored.
+> **Good to know**: The `matcher` values need to be constants so they can be statically analyzed at build-time. Dynamic values such as variables will be ignored.
 
 Configured matchers:
 
@@ -92,7 +92,7 @@ Configured matchers:
 
 Read more details on [path-to-regexp](https://github.com/pillarjs/path-to-regexp#path-to-regexp-1) documentation.
 
-> **Note**: For backward compatibility, Next.js always considers `/public` as `/public/index`. Therefore, a matcher of `/public/:path` will match.
+> **Good to know**: For backward compatibility, Next.js always considers `/public` as `/public/index`. Therefore, a matcher of `/public/:path` will match.
 
 ### Conditional Statements
 
@@ -214,7 +214,7 @@ export function middleware(request) {
 }
 ```
 
-> **Note**: Avoid setting large headers as it might cause [431 Request Header Fields Too Large](https://developer.mozilla.org/en-US/docs/Web/HTTP/Status/431) error depending on your backend web server configuration.
+> **Good to know**: Avoid setting large headers as it might cause [431 Request Header Fields Too Large](https://developer.mozilla.org/en-US/docs/Web/HTTP/Status/431) error depending on your backend web server configuration.
 
 ## Producing a Response
 

@@ -141,7 +141,7 @@ There is no "right" or "wrong" way when it comes to organizing your own files an
 
 The following section lists a very high-level overview of common strategies. The simplest takeaway is to choose a strategy that works for you and your team and be consistent across the project.
 
-> **Note:** In our examples below, we're using `components` and `lib` folders as generalized placeholders, their naming has no special framework significance and your projects might use other folders like `ui`, `utils`, `hooks`, `styles`, etc.
+> **Good to know**: In our examples below, we're using `components` and `lib` folders as generalized placeholders, their naming has no special framework significance and your projects might use other folders like `ui`, `utils`, `hooks`, `styles`, etc.
 
 ### Store project files outside of `app`
 

@@ -40,7 +40,7 @@ In version 13, Next.js introduced a new **App Router** built on [React Server Co
 
 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.
 
-> **Good to know:** The App Router takes priority over the Pages Router. Routes across directories should not resolve to the same URL path and will cause a build-time error to prevent a conflict.
+> **Good to know**: The App Router takes priority over the Pages Router. Routes across directories should not resolve to the same URL path and will cause a build-time error to prevent a conflict.
 
 <Image
   alt="Next.js App Directory"
@@ -99,7 +99,7 @@ Next.js provides a set of special files to create UI with specific behavior in n
 | [`template`](/docs/app/building-your-application/routing/pages-and-layouts#templates) | Specialized re-rendered Layout UI                                                              |
 | [`default`](/docs/app/api-reference/file-conventions/default)                         | Fallback UI for [Parallel Routes](/docs/app/building-your-application/routing/parallel-routes) |
 
-> **Good to know:** `.js`, `.jsx`, or `.tsx` file extensions can be used for special files.
+> **Good to know**: `.js`, `.jsx`, or `.tsx` file extensions can be used for special files.
 
 ## Component Hierarchy
 

@@ -36,7 +36,7 @@ This table summarizes how [dynamic functions](#dynamic-functions) and [caching](
 
 Note how dynamic functions always opt the route into dynamic rendering, regardless of whether the data fetching is cached or not. In other words, static rendering is dependent not only on the data fetching behavior, but also on the dynamic functions used in the route.
 
-> **Note:** In the future, Next.js will introduce hybrid server-side rendering where layouts and pages in a route can be independently statically or dynamically rendered, instead of the whole route.
+> **Good to know**: In the future, Next.js will introduce hybrid server-side rendering where layouts and pages in a route can be independently statically or dynamically rendered, instead of the whole route.
 
 ### Dynamic Functions
 

@@ -22,7 +22,7 @@ There are two environments where your application code can be rendered: the clie
 - The **client** refers to the browser on a user's device that sends a request to a server for your application code. It then turns the response from the server into an interface the user can interact with.
 - The **server** refers to the computer in a data center that stores your application code, receives requests from a client, does some computation, and sends back an appropriate response.
 
-> **Note:** Server can refer to computers in regions where your application is deployed to, the [Edge Network](https://vercel.com/docs/concepts/edge-network/overview) where your application code is distributed, or [Content Delivery Networks (CDNs)](https://developer.mozilla.org/en-US/docs/Glossary/CDN) where the result of the rendering work can be cached.
+> **Good to know**: Server can refer to computers in regions where your application is deployed to, the [Edge Network](https://vercel.com/docs/concepts/edge-network/overview) where your application code is distributed, or [Content Delivery Networks (CDNs)](https://developer.mozilla.org/en-US/docs/Glossary/CDN) where the result of the rendering work can be cached.
 
 ## Component-level Client and Server Rendering
 
@@ -42,7 +42,7 @@ In addition to client-side and server-side rendering with React components, Next
 
 With **Static Rendering**, both Server _and_ Client Components can be prerendered on the server at **build time**. The result of the work is [cached](/docs/app/building-your-application/data-fetching/caching) and reused on subsequent requests. The cached result can also be [revalidated](/docs/app/building-your-application/data-fetching#revalidating-data).
 
-> **Note:** This is equivalent to [Static Site Generation (SSG)](/docs/pages/building-your-application/rendering/static-site-generation) and [Incremental Static Regeneration (ISR)](/docs/pages/building-your-application/rendering/incremental-static-regeneration) in the [Pages Router](/docs/pages/building-your-application/rendering).
+> **Good to know**: This is equivalent to [Static Site Generation (SSG)](/docs/pages/building-your-application/rendering/static-site-generation) and [Incremental Static Regeneration (ISR)](/docs/pages/building-your-application/rendering/incremental-static-regeneration) in the [Pages Router](/docs/pages/building-your-application/rendering).
 
 Server and Client Components are rendered differently during Static Rendering:
 
@@ -53,7 +53,7 @@ Server and Client Components are rendered differently during Static Rendering:
 
 With Dynamic Rendering, both Server _and_ Client Components are rendered on the server at **request time**. The result of the work is not cached.
 
-> **Note:** This is equivalent to [Server-Side Rendering (`getServerSideProps()`)](/docs/pages/building-your-application/rendering/server-side-rendering) in the [Pages Router](/docs/pages/building-your-application/rendering).
+> **Good to know**: This is equivalent to [Server-Side Rendering (`getServerSideProps()`)](/docs/pages/building-your-application/rendering/server-side-rendering) in the [Pages Router](/docs/pages/building-your-application/rendering).
 
 To learn more about static and dynamic behavior, see the [Static and Dynamic Rendering](/docs/app/building-your-application/rendering/static-and-dynamic-rendering) page. To learn more about caching, see the [Caching](/docs/app/building-your-application/data-fetching/caching) sections.