docs: improve wording on some pages according to alex.js (#11973)
This commit is contained in:
parent
e0d4ae0447
commit
26df01800d
16 changed files with 18 additions and 18 deletions
|
@ -38,5 +38,5 @@ In development you'll know if `pages/about.js` is optimized or not thanks to the
|
|||
|
||||
## Caveats
|
||||
|
||||
- If you have a [custom `App`](/docs/advanced-features/custom-app.md) with `getInitialProps` then this optimization will be disabled for all pages.
|
||||
- If you have a [custom `App`](/docs/advanced-features/custom-app.md) with `getInitialProps` then this optimization will be turned off for all pages.
|
||||
- If you have a [custom `Document`](/docs/advanced-features/custom-document.md) with `getInitialProps` be sure you check if `ctx.req` is defined before assuming the page is server-side rendered. `ctx.req` will be `undefined` for pages that are prerendered.
|
||||
|
|
|
@ -45,7 +45,7 @@ Custom attributes are allowed as props, like `lang`:
|
|||
|
||||
The `ctx` object is equivalent to the one received in [`getInitialProps`](/docs/api-reference/data-fetching/getInitialProps.md#context-object), with one addition:
|
||||
|
||||
- `renderPage`: `Function` - a callback that executes the actual React rendering logic (synchronously). It's useful to decorate this function in order to support server-rendering wrappers like Aphrodite's [`renderStatic`](https://github.com/Khan/aphrodite#server-side-rendering)
|
||||
- `renderPage`: `Function` - a callback that runs the actual React rendering logic (synchronously). It's useful to decorate this function in order to support server-rendering wrappers like Aphrodite's [`renderStatic`](https://github.com/Khan/aphrodite#server-side-rendering)
|
||||
|
||||
## Caveats
|
||||
|
||||
|
|
|
@ -94,6 +94,6 @@ module.exports = {
|
|||
}
|
||||
```
|
||||
|
||||
> Note that `useFileSystemPublicRoutes` simply disables filename routes from SSR; client-side routing may still access those paths. When using this option, you should guard against navigation to routes you do not want programmatically.
|
||||
> Note that `useFileSystemPublicRoutes` disables filename routes from SSR; client-side routing may still access those paths. When using this option, you should guard against navigation to routes you do not want programmatically.
|
||||
|
||||
> You may also wish to configure the client-side Router to disallow client-side redirects to filename routes; for that refer to [`Router.beforePopState`](/docs/api-reference/next/router.md#router.beforePopState).
|
||||
|
|
|
@ -57,4 +57,4 @@ To learn more about the available options for each config, visit their documenta
|
|||
|
||||
> Next.js uses the **current** Node.js version for server-side compilations.
|
||||
|
||||
> The `modules` option on `"preset-env"` should be kept to `false`, otherwise webpack code splitting is disabled.
|
||||
> The `modules` option on `"preset-env"` should be kept to `false`, otherwise webpack code splitting is turned off.
|
||||
|
|
|
@ -27,7 +27,7 @@ There are no special zones related APIs. You only need to do following:
|
|||
|
||||
You can merge zones using any HTTP proxy.
|
||||
|
||||
For [ZEIT Now](https://zeit.co/now), you can use a single `now.json` to deploy both apps. It allows you to easily define routing routes for multiple apps like below:
|
||||
For [ZEIT Now](https://zeit.co/now), you can use a single `now.json` to deploy both apps. It allows you to define routing routes for multiple apps like below:
|
||||
|
||||
```json
|
||||
{
|
||||
|
|
|
@ -18,7 +18,7 @@ Next.js has the feature called **Preview Mode** which solves this problem. Here
|
|||
|
||||
First, create a **preview API route**. It can have any name - e.g. `pages/api/preview.js` (or `.ts` if using TypeScript).
|
||||
|
||||
In this API route, you need to call `setPreviewData` on the response object. The argument for `setPreviewData` should be an object, and this can be used by `getStaticProps` (more on this later). For now, we’ll just use `{}`.
|
||||
In this API route, you need to call `setPreviewData` on the response object. The argument for `setPreviewData` should be an object, and this can be used by `getStaticProps` (more on this later). For now, we’ll use `{}`.
|
||||
|
||||
```js
|
||||
export default (req, res) => {
|
||||
|
|
|
@ -21,7 +21,7 @@ The way `next export` works is by prerendering all pages to HTML; it does so bas
|
|||
|
||||
## How to use it
|
||||
|
||||
Simply develop your app as you normally do with Next.js. Then run:
|
||||
Develop your app as you normally do with Next.js. Then run:
|
||||
|
||||
```bash
|
||||
next build && next export
|
||||
|
|
|
@ -65,7 +65,7 @@ export default Page
|
|||
|
||||
Data returned from `getInitialProps` is serialized when server rendering, similar to what [`JSON.stringify`](https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/JSON/stringify) does. Make sure the returned object from `getInitialProps` is a plain `Object` and not using `Date`, `Map` or `Set`.
|
||||
|
||||
For the initial page load, `getInitialProps` will execute on the server only. `getInitialProps` will only be executed on the client when navigating to a different route via the [`next/link`](/docs/api-reference/next/link.md) component or by using [`next/router`](/docs/api-reference/next/router.md).
|
||||
For the initial page load, `getInitialProps` will run on the server only. `getInitialProps` will then run on the client when navigating to a different route via the [`next/link`](/docs/api-reference/next/link.md) component or by using [`next/router`](/docs/api-reference/next/router.md).
|
||||
|
||||
## Context Object
|
||||
|
||||
|
|
|
@ -176,7 +176,7 @@ The child of `Link` is `<img>` instead of `<a>`. `Link` will send the `onClick`
|
|||
|
||||
## Disable scrolling to the top of the page
|
||||
|
||||
The default behavior of `Link` is to scroll to the top of the page. When there is a hash defined it will scroll to the specific id, just like a normal `<a>` tag. To prevent scrolling to the top / hash `scroll={false}` can be added to `Link`:
|
||||
The default behavior of `Link` is to scroll to the top of the page. When there is a hash defined it will scroll to the specific id, like a normal `<a>` tag. To prevent scrolling to the top / hash `scroll={false}` can be added to `Link`:
|
||||
|
||||
```jsx
|
||||
<Link href="/?counter=10" scroll={false}>
|
||||
|
|
|
@ -177,7 +177,7 @@ Router.beforePopState(({ url, as, options }) => {
|
|||
|
||||
`Router.beforePopState(cb: () => boolean)`
|
||||
|
||||
- `cb` - The function to execute on incoming `popstate` events. The function receives the state of the event as an object with the following props:
|
||||
- `cb` - The function to run on incoming `popstate` events. The function receives the state of the event as an object with the following props:
|
||||
- `url`: `String` - the route for the new state. This is usually the name of a `page`
|
||||
- `as`: `String` - the url that will be shown in the browser
|
||||
- `options`: `Object` - Additional options sent by [Router.push](#router.push)
|
||||
|
|
|
@ -18,7 +18,7 @@ API routes provide a straightforward solution to build your **API** with Next.js
|
|||
|
||||
Any file inside the folder `pages/api` is mapped to `/api/*` and will be treated as an API endpoint instead of a `page`.
|
||||
|
||||
For example, the following API route `pages/api/user.js` handles a simple `json` response:
|
||||
For example, the following API route `pages/api/user.js` handles a `json` response:
|
||||
|
||||
```js
|
||||
export default (req, res) => {
|
||||
|
|
|
@ -8,7 +8,7 @@ description: 'Next.js has 2 pre-rendering modes: Static Generation and Server-si
|
|||
|
||||
In the [Pages documentation](/docs/basic-features/pages.md), we’ve explained that Next.js has two forms of pre-rendering: **Static Generation** and **Server-side Rendering**. In this page, we’ll talk in depths about data fetching strategies for each case. We recommend you to [read through the Pages documentation](/docs/basic-features/pages.md) first if you haven’t done so.
|
||||
|
||||
We’ll talk about the three special Next.js functions you can use to fetch data for pre-rendering:
|
||||
We’ll talk about the three unique Next.js functions you can use to fetch data for pre-rendering:
|
||||
|
||||
- [`getStaticProps`](#getstaticprops-static-generation) (Static Generation): Fetch data at **build time**.
|
||||
- [`getStaticPaths`](#getstaticpaths-static-generation) (Static Generation): Specify [dynamic routes](/docs/routing/dynamic-routes.md) to pre-render based on data.
|
||||
|
@ -467,7 +467,7 @@ This approach works well for user dashboard pages, for example. Because a dashbo
|
|||
|
||||
### SWR
|
||||
|
||||
The team behind Next.js has created a React hook for data fetching called [**SWR**](https://swr.now.sh/). We highly recommend it If you’re fetching data on the client side. It handles caching, revalidation, focus tracking, refetching on interval, and more. And the usage is very simple:
|
||||
The team behind Next.js has created a React hook for data fetching called [**SWR**](https://swr.now.sh/). We highly recommend it if you’re fetching data on the client side. It handles caching, revalidation, focus tracking, refetching on interval, and more. And you can use it like so:
|
||||
|
||||
```jsx
|
||||
import useSWR from 'swr'
|
||||
|
|
|
@ -61,7 +61,7 @@ function About() {
|
|||
export default About
|
||||
```
|
||||
|
||||
Note that this page does not need to fetch any external data to be pre-rendered. In cases like this, Next.js simply generates a single HTML file per page during build time.
|
||||
Note that this page does not need to fetch any external data to be pre-rendered. In cases like this, Next.js generates a single HTML file per page during build time.
|
||||
|
||||
### Static Generation with data
|
||||
|
||||
|
@ -239,7 +239,7 @@ To learn more about how `getServerSideProps` works, check out our [Data Fetching
|
|||
|
||||
We've discussed two forms of pre-rendering for Next.js.
|
||||
|
||||
- **Static Generation (Recommended):** The HTML is generated at **build time** and will be reused on each request. To make a page use Static Generation, just export the page component, or export `getStaticProps` (and `getStaticPaths` if necessary). It's great for pages that can be pre-rendered ahead of a user's request. You can also use it with Client-side Rendering to bring in additional data.
|
||||
- **Static Generation (Recommended):** The HTML is generated at **build time** and will be reused on each request. To make a page use Static Generation, either export the page component, or export `getStaticProps` (and `getStaticPaths` if necessary). It's great for pages that can be pre-rendered ahead of a user's request. You can also use it with Client-side Rendering to bring in additional data.
|
||||
- **Server-side Rendering:** The HTML is generated on **each request**. To make a page use Server-side Rendering, export `getServerSideProps`. Because Server-side Rendering results in slower performance than Static Generation, use this only if absolutely necessary.
|
||||
|
||||
## More Examples
|
||||
|
|
|
@ -41,7 +41,7 @@ You're now ready to start converting files from `.js` to `.tsx` and leveraging t
|
|||
|
||||
> A file named `next-env.d.ts` will be created in the root of your project. This file ensures Next.js types are picked up by the TypeScript compiler. **You cannot remove it**, however, you can edit it (but you don't need to).
|
||||
|
||||
> Next.js `strict` mode is disabled by default. When you feel comfortable with TypeScript, it's recommended to turn it on in your `tsconfig.json`.
|
||||
> Next.js `strict` mode is turned off by default. When you feel comfortable with TypeScript, it's recommended to turn it on in your `tsconfig.json`.
|
||||
|
||||
By default, Next.js reports TypeScript errors during development for pages you are actively working on. TypeScript errors for inactive pages **do not** block the development process.
|
||||
|
||||
|
|
|
@ -16,7 +16,7 @@ Then, follow these steps:
|
|||
|
||||
1. [Sign up to ZEIT Now](https://zeit.co/signup) (no credit card is required).
|
||||
2. After signing up, you’ll arrive on the [“Import Project”](https://zeit.co/import) page. Under “From Git Repository”, choose the Git provider you use and set up an integration. (Instructions: [GitHub](https://zeit.co/docs/v2/git-integrations/zeit-now-for-github) / [GitLab](https://zeit.co/docs/v2/git-integrations/zeit-now-for-gitlab) / [BitBucket](https://zeit.co/docs/v2/git-integrations/zeit-now-for-bitbucket)).
|
||||
3. Once that’s set up, click “Import Project From …” and import your Next.js app. It auto-detects that your app is using Next.js and sets up the build configuration for you. No need to change anything — everything just works!
|
||||
3. Once that’s set up, click “Import Project From …” and import your Next.js app. It auto-detects that your app is using Next.js and sets up the build configuration for you. No need to change anything — everything should work just fine!
|
||||
4. After importing, it’ll deploy your Next.js app and provide you with a deployment URL. Click “Visit” to see your app in production.
|
||||
|
||||
Congratulations! You’ve just deployed your Next.js app! If you have questions, take a look at the [ZEIT Now documentation](https://zeit.co/docs).
|
||||
|
|
|
@ -36,7 +36,7 @@ To match a dynamic segment you can use the bracket syntax. This allows you to ma
|
|||
|
||||
The Next.js router allows you to do client-side route transitions between pages, similarly to a single-page application.
|
||||
|
||||
A special React component called `Link` is provided to do this client-side route transition.
|
||||
A React component called `Link` is provided to do this client-side route transition.
|
||||
|
||||
```jsx
|
||||
import Link from 'next/link'
|
||||
|
|
Loading…
Reference in a new issue