mirror of
https://github.com/nuxt/nuxt.git
synced 2025-02-16 21:58:19 +00:00
docs: improve sentences writing (#3702)
This commit is contained in:
Clément Ollivier
GitHub
parent
ff88d91bae
commit
831ed1c994
@ -143,7 +143,7 @@ In case you need to extend options provided by `./.nuxt/tsconfig.json` further,
|
||||
|
||||
## Migrate Composition API
|
||||
|
||||
If you were previously using `@vue/composition-api` or `@nuxtjs/composition-api`, please read the [composition api migration guide](/getting-started/bridge-composition-api).
|
||||
If you were using `@vue/composition-api` or `@nuxtjs/composition-api`, please read the [composition api migration guide](/getting-started/bridge-composition-api).
|
||||
|
||||
### Migrate from CommonJS to ESM
|
||||
|
||||
@ -151,7 +151,7 @@ Nuxt 3 natively supports TypeScript and ECMAScript Modules. Please check [Native
|
||||
|
||||
## Remove incompatible and obsolete modules
|
||||
|
||||
- Remove `@nuxt/content` (1.x). A rewrite for nuxt 3 is planned (2.x)
|
||||
- Remove `@nuxt/content` (1.x). A rewrite for Nuxt 3 is planned (2.x)
|
||||
- Remove `nuxt-vite`: Bridge enables same functionality
|
||||
- Remove `@nuxt/typescript-build`: Bridge enables same functionality
|
||||
- Remove `@nuxt/typescript-runtime` and `nuxt-ts`: Nuxt 2 has built-in runtime support
|
||||
@ -219,7 +219,7 @@ export default defineNuxtConfig({
|
||||
```
|
||||
|
||||
This `useMeta` composable uses `@vueuse/head` under the hood (rather than `vue-meta`) to manipulate your `<head>`.
|
||||
Accordingly, it is recommended not to use both the native Nuxt 2 `head()` properties as well as `useMeta`, as they may conflict.
|
||||
Accordingly, we recommend not to use both the native Nuxt 2 `head()` properties as well as `useMeta`, as they may conflict.
|
||||
|
||||
For more information on how to use this composable, see [the docs](/docs/usage/meta-tags#usemeta-composable).
|
||||
|
||||
|
||||
@ -114,7 +114,7 @@ This function has been removed, but its use cases can be met by using `useNuxtAp
|
||||
|
||||
These two functions have been replaced with a new composable that works very similarly under the hood: `useState`.
|
||||
|
||||
The key differences are that you must provide a _key_ for this state (which previously will have been generated automatically for `ssrRef` and `shallowSsrRef`), and that it can only be called within a Nuxt 3 plugin (which is defined by `defineNuxtPlugin`) or a component instance. (In other words, you cannot use `useState` with a global/ambient context, because of the danger of shared state across requests.)
|
||||
The key differences are that you must provide a _key_ for this state (which Nuxt generated automatically for `ssrRef` and `shallowSsrRef`), and that it can only be called within a Nuxt 3 plugin (which is defined by `defineNuxtPlugin`) or a component instance. (In other words, you cannot use `useState` with a global/ambient context, because of the danger of shared state across requests.)
|
||||
|
||||
```diff
|
||||
- import { ssrRef } from '@nuxtjs/composition-api'
|
||||
|
||||
@ -107,7 +107,7 @@ export default () => { }
|
||||
|
||||
With Nuxt 3, Nuxt is now a build-time-only dependency, which means that modules shouldn't attempt to hook into the Nuxt runtime.
|
||||
|
||||
Your module needs should work even if it's only added to [`buildModules`](/docs/directory-structure/nuxt.config#buildmodules) (instead of `modules`). For example:
|
||||
Your module should work even if it's only added to [`buildModules`](/docs/directory-structure/nuxt.config#buildmodules) (instead of `modules`). For example:
|
||||
|
||||
- Avoid updating `process.env` within a Nuxt module and reading by a nuxt plugin; use [`runtimeConfig`](/docs/directory-structure/nuxt.config#publicruntimeconfig) instead.
|
||||
- (*) Avoid depending on runtime hooks like `vue-renderer:*` for production
|
||||
@ -115,18 +115,16 @@ Your module needs should work even if it's only added to [`buildModules`](/docs/
|
||||
|
||||
(*) Unless it is for `nuxt dev` purpose only and guarded with `if (nuxt.options.dev) { }`.
|
||||
|
||||
### Add module meta
|
||||
|
||||
Ensure your module is exporting meta object.
|
||||
|
||||
\[TODO\]
|
||||
::alert{type=info icon=🔎}
|
||||
Continue reading about Nuxt 3 modules in the [Modules guide](/docs/advanced/modules).
|
||||
::
|
||||
|
||||
### Use TypeScript (optional)
|
||||
|
||||
While it is not essential, most of the Nuxt ecosystem is shifting to use TypeScript, so it is highly recommended to consider migration.
|
||||
|
||||
::alert{icon=💡}
|
||||
You can start migration by simply renaming `.js` files, to `.ts`. TypeScript is designed to be progressive!
|
||||
You can start migration by renaming `.js` files, to `.ts`. TypeScript is designed to be progressive!
|
||||
::
|
||||
|
||||
::alert{icon=💡}
|
||||
|
||||
@ -16,7 +16,7 @@ To understand what is Nuxt, we need to understand what we need to create a moder
|
||||
|
||||
This is only the tip of the iceberg, imagine having to set up all of this for your project, make it work, and then, maintain it over time. We have been doing this since October 2016, tuning all the configurations to provide the best optimization and performance for any Vue application.
|
||||
|
||||
Nuxt takes care of all of this so you can focus on what matters: **creating your web application**.
|
||||
Nuxt takes care of this so you can focus on what matters: **creating your web application**.
|
||||
|
||||
On top of this setup, Nuxt provides a [directory structure](/docs/directory-structure/app) to follow, focused on specific features to keep your focus on creating, not configuring.
|
||||
|
||||
|
||||
@ -21,7 +21,7 @@ Nuxt has always used Vue as a frontend framework. We chose to build Nuxt in top
|
||||
|
||||
### Components auto-imports
|
||||
|
||||
Every Vue components created in the [`components/` directory](/docs/directory-structure/components) of a Nuxt project will be available in your project without having to import them. If a component is not used anywhere, it will not be included in your production’s code.
|
||||
Every Vue components created in the [`components/` directory](/docs/directory-structure/components) of a Nuxt project will be available in your project without having to import them. If a component is not used anywhere, your production’s code will not include it.
|
||||
|
||||
### Vue Router
|
||||
|
||||
@ -39,7 +39,7 @@ Inside the `<template>` of the component, we use the `<Welcome>` component creat
|
||||
Try to replace the `<template>`’s content with a custom welcome message. The browser window on the right will automatically render the changes without reloading.
|
||||
|
||||
::alert{type="info"}
|
||||
💡 If you are familiar with Vue, you might wonder where is the `main.js` file that creates a Vue app. This part is done by Nuxt behind the scene.
|
||||
💡 If you are familiar with Vue, you might wonder where is the `main.js` file that creates a Vue app. Nuxt does this part behind the scene.
|
||||
::
|
||||
|
||||
**If you were a previous user of Nuxt 2 or Vue 2, keep reading to get a feel of the differences between Vue 2 and Vue 3, and how Nuxt integrates those evolutions.**
|
||||
@ -62,7 +62,7 @@ This results in faster first rendering (component creation) and updates, and les
|
||||
|
||||
### Smaller bundle
|
||||
|
||||
With Vue 3 and Nuxt 3, a focus has been put on bundle size reduction. With version 3, most of Vue’s functionality, including template directives and built-in components are tree-shakeable. They will not be included in your production bundle if you don’t use them.
|
||||
With Vue 3 and Nuxt 3, a focus has been put on bundle size reduction. With version 3, most of Vue’s functionality, including template directives and built-in components are tree-shakeable. Your production bundle will not include them if you don’t use them.
|
||||
|
||||
This way, a minimal Vue 3 application can be reduced to 12 kb gzipped.
|
||||
|
||||
@ -105,7 +105,7 @@ The goal of Nuxt 3 is to provide a great developer experience around the composi
|
||||
|
||||
### Typescript support
|
||||
|
||||
Both Vue 3 and Nuxt 3 have been written in Typescript. A fully typed codebase prevents mistakes and documents APIs usage. This doesn’t mean that you have to write your application in Typescript to take advantage of it. With Nuxt 3, you can opt-in by just renaming your file from `.js` to `.ts` , or add `<script lang="ts">` in a component.
|
||||
Both Vue 3 and Nuxt 3 are written in Typescript. A fully typed codebase prevents mistakes and documents APIs usage. This doesn’t mean that you have to write your application in Typescript to take advantage of it. With Nuxt 3, you can opt-in by renaming your file from `.js` to `.ts` , or add `<script lang="ts">` in a component.
|
||||
|
||||
::alert{type="info"}
|
||||
🔎 [Read the details about Typescript in Nuxt 3](/concepts/typescript)
|
||||
|
||||
@ -14,13 +14,13 @@ While this technique allows building complex and dynamic UIs with smooth page tr
|
||||
### Pros
|
||||
|
||||
- **Development speed**: When working entirely on the client-side, we don't have to worry about the server compatibility of the code, for example, by using browser-only APIs like the `window` object.
|
||||
- **Cheaper:** Running a server adds a cost of infrastructure as you would need to run on a platform that supports Javascript. We can host Client-only applications on any static server, just with HTML, CSS, and Javascript files.
|
||||
- **Cheaper:** Running a server adds a cost of infrastructure as you would need to run on a platform that supports Javascript. We can host Client-only applications on any static server with HTML, CSS, and Javascript files.
|
||||
- **Offline:** Because code entirely runs in the browser, it can nicely keep working while the internet is unavailable.
|
||||
|
||||
### Cons
|
||||
|
||||
- **Performance**: The user has to wait for the browser to download, parse and run javascript files. Depending on the network for the download part and the user's device for the parsing and execution, this can take some time and impact your user's experience.
|
||||
- **Search Engine Optimization**: Indexing and updating the content delivered via client-side rendering takes more time than an HTML document already built. This is related to the performance drawback we discussed, as search engine crawlers won't wait for the interface to be fully rendered in their first try to index the page. Therefore, your content will take more time to show and update in search results pages with pure client-side rendering.
|
||||
- **Search Engine Optimization**: Indexing and updating the content delivered via client-side rendering takes more time than an HTML document already built. This is related to the performance drawback we discussed, as search engine crawlers won't wait for the interface to be fully rendered in their first try to index the page. Your content will take more time to show and update in search results pages with pure client-side rendering.
|
||||
|
||||
### Examples
|
||||
|
||||
@ -28,9 +28,9 @@ Client-side rendering is a good choice for heavily interactive **web application
|
||||
|
||||
## Universal Rendering
|
||||
|
||||
When the browser requests a URL with universal (client-side + server-side) rendering enabled, a fully rendered HTML page is returned to the browser. Whether the page has been generated in advance and cached or is rendered on the fly, at some point, Nuxt has run the Javascript (Vue.js) code in a server environment, producing an HTML document. Users immediately get the content of our application, contrary to client-side rendering. This step is similar to traditional **server-side rendering** performed by PHP or Ruby applications.
|
||||
When the browser requests a URL with universal (client-side + server-side) rendering enabled, the server returns a fully rendered HTML page to the browser. Whether the page has been generated in advance and cached or is rendered on the fly, at some point, Nuxt has run the Javascript (Vue.js) code in a server environment, producing an HTML document. Users immediately get the content of our application, contrary to client-side rendering. This step is similar to traditional **server-side rendering** performed by PHP or Ruby applications.
|
||||
|
||||
To not lose the benefits of the client-side rendering method, such as dynamic interfaces and pages transitions, the javascript code that runs on the Server is loaded by the client in the background once the HTML document has been downloaded. Once it is interpreted again by the browser (hence **Universal rendering**), Vue.js takes control of the document and enables interactivity.
|
||||
To not lose the benefits of the client-side rendering method, such as dynamic interfaces and pages transitions, the Client loads the javascript code that runs on the Server in the background once the HTML document has been downloaded. It is interpreted again by the browser (hence **Universal rendering**) and Vue.js takes control of the document and enables interactivity.
|
||||
|
||||
Making a static page interactive in the browser is called "Hydration."
|
||||
|
||||
|
||||
@ -1,15 +1,15 @@
|
||||
# Auto imports
|
||||
|
||||
Nuxt auto-imports helper functions, composables and Vue APIs to use across your application without explicitly importing them. Based on the directory structure, every Nuxt application can also use auto-imports for its own components, composables and plugins. These functions can be used in components, composables or plugins.
|
||||
Nuxt auto-imports helper functions, composables and Vue APIs to use across your application without explicitly importing them. Based on the directory structure, every Nuxt application can also use auto-imports for its own components, composables and plugins. Components, composables or plugins can use these functions.
|
||||
|
||||
Contrary to a classic global declaration, Nuxt preserves typings and IDEs completions and hints, and only includes what is actually used in your production code.
|
||||
|
||||
::alert{type=info}
|
||||
💡 In the documentation, every function that is not explicitly imported is auto-imported by Nuxt and can be used as-is in your code.
|
||||
::alert{type=info icon=💡}
|
||||
In the documentation, every function that is not explicitly imported is auto-imported by Nuxt and can be used as-is in your code.
|
||||
::
|
||||
|
||||
::alert{type=info}
|
||||
🚧 We are working on a proper API reference that will include every Nuxt auto-imports. For now, you can find a reference on the framework repository: [github.com/nuxt/framework/blob/main/packages/nuxt3/src/auto-imports/imports.ts](https://github.com/nuxt/framework/blob/main/packages/nuxt3/src/auto-imports/imports.ts)
|
||||
::alert{type=info icon=🚧}
|
||||
We are working on a proper API reference that will include every Nuxt auto-imports. For now, you can find a reference on the framework repository: [github.com/nuxt/framework/blob/main/packages/nuxt3/src/auto-imports/imports.ts](https://github.com/nuxt/framework/blob/main/packages/nuxt3/src/auto-imports/imports.ts)
|
||||
::
|
||||
|
||||
::alert{type=warning}
|
||||
|
||||
@ -17,7 +17,7 @@ This engine has many benefits:
|
||||
|
||||
Server [API endpoints](/docs/directory-structure/server#api-routes) and [Middleware](/docs/directory-structure/server#server-middleware) are added by Nitro that internally uses [h3](https://github.com/unjs/h3).
|
||||
|
||||
There are a number of key features, including:
|
||||
Key features include:
|
||||
|
||||
- Handlers can directly return objects/arrays for an automatically-handled JSON response
|
||||
- Handlers can return promises, which will be awaited (`res.end()` and `next()` are also supported)
|
||||
@ -31,12 +31,12 @@ Learn more about the API layer in the [`server/`](/docs/directory-structure/serv
|
||||
|
||||
## Direct API calls
|
||||
|
||||
Nitro allows 'direct' calling of routes via the globally-available `$fetch` helper. This will make an API call to the server if run on the browser, but will simply call the relevant function if run on the server, **saving an additional API call**.
|
||||
Nitro allows 'direct' calling of routes via the globally-available `$fetch` helper. This will make an API call to the server if run on the browser, but will directly call the relevant function if run on the server, **saving an additional API call**.
|
||||
|
||||
`$fetch` API is using [ohmyfetch](https://github.com/unjs/ohmyfetch), with key features including:
|
||||
|
||||
- Automatic parsing of JSON responses (with access to raw response if needed)
|
||||
- Request body and params are automatically handled, with correct `Content-Type` headers being added
|
||||
- Request body and params are automatically handled, with correct `Content-Type` headers
|
||||
|
||||
For more information on `$fetch` features, check out [ohmyfetch](https://github.com/unjs/ohmyfetch).
|
||||
|
||||
@ -50,9 +50,9 @@ You can access these types when using `$fetch()` or `useFetch()`.
|
||||
|
||||
Nitro produces a standalone server dist that is independent of `node_modules`.
|
||||
|
||||
The server in Nuxt 2 is not standalone, but requires part of nuxt core to be involved running `nuxt start` (with the [`nuxt-start`](https://www.npmjs.com/package/nuxt-start) or [`nuxt`](https://www.npmjs.com/package/nuxt) distributions) or custom programmatic usage, which was fragile and prone to breakage and not suitable for serverless and service-worker environments.
|
||||
The server in Nuxt 2 is not standalone, but requires part of Nuxt core to be involved running `nuxt start` (with the [`nuxt-start`](https://www.npmjs.com/package/nuxt-start) or [`nuxt`](https://www.npmjs.com/package/nuxt) distributions) or custom programmatic usage, which was fragile and prone to breakage and not suitable for serverless and service-worker environments.
|
||||
|
||||
This dist is generated when running `nuxt build` into a [`.output`](/docs/directory-structure/output) directory.
|
||||
Nuxt 3 generates this dist when running `nuxt build` into a [`.output`](/docs/directory-structure/output) directory.
|
||||
|
||||
The output is combined with both runtime code to run your Nuxt server in any environment (including experimental browser Service Workers!) and serve you static files, making it a true hybrid framework for the JAMstack. In addition, a native storage layer is implemented, supporting multi source, drivers and local assets.
|
||||
|
||||
|
||||
@ -35,7 +35,7 @@ However, there are some key differences with actual spec; here's [a helpful expl
|
||||
|
||||
### What is 'Native' ESM?
|
||||
|
||||
You may have been writing your app using ESM syntax for a long time. After all, it's natively supported by the browser, and in Nuxt 2 we simply compiled all the code you wrote to the appropriate format (CJS for server, ESM for browser).
|
||||
You may have been writing your app using ESM syntax for a long time. After all, it's natively supported by the browser, and in Nuxt 2 we compiled all the code you wrote to the appropriate format (CJS for server, ESM for browser).
|
||||
|
||||
When using modules you'd install into your package, things were a little different. A sample library might expose both CJS and ESM versions, and let us pick which one we wanted:
|
||||
|
||||
@ -47,7 +47,7 @@ When using modules you'd install into your package, things were a little differe
|
||||
}
|
||||
```
|
||||
|
||||
So in Nuxt 2, the bundler (webpack) would simply pull in the CJS file ('main') for the server build, and use the ESM file ('module') for the client build.
|
||||
So in Nuxt 2, the bundler (webpack) would pull in the CJS file ('main') for the server build, and use the ESM file ('module') for the client build.
|
||||
|
||||
However, in recent Node.js LTS releases, it is now possible to [use native ESM module](https://nodejs.org/api/esm.html) within Node.js. That means that Node.js itself can process JavaScript using ESM syntax, although it doesn't do it by default. The two most common ways to enable ESM syntax are:
|
||||
|
||||
@ -72,7 +72,7 @@ Node supports the following kinds of imports (see [docs](https://nodejs.org/api/
|
||||
|
||||
For a long time module authors have been producing ESM-syntax builds but using conventions like `.esm.js` or `.es.js`, which they have added to the `module` field in their `package.json`. This hasn't been a problem until now because they have only been used by bundlers like webpack, which don't especially care about the file extension.
|
||||
|
||||
However, if you try to import a package with an `.esm.js` file in a Node.js ESM context, it just won't work, and you'll get an error like:
|
||||
However, if you try to import a package with an `.esm.js` file in a Node.js ESM context, it won't work, and you'll get an error like:
|
||||
|
||||
```bash
|
||||
(node:22145) Warning: To load an ES module, set "type": "module" in the package.json or use the .mjs extension.
|
||||
@ -206,7 +206,7 @@ console.log(interopDefault(myModule)) // { foo: 'bar', baz: 'qux' }
|
||||
|
||||
## Library author guide
|
||||
|
||||
The good news is that it's relatively simple to fix issues of ESM compatibility. There are really two main options:
|
||||
The good news is that it's relatively simple to fix issues of ESM compatibility. There are two main options:
|
||||
|
||||
1. **You can rename your ESM files to end with `.mjs`.**
|
||||
|
||||
|
||||
@ -12,7 +12,7 @@ yarn nuxi typecheck
|
||||
|
||||
## Auto-generated types
|
||||
|
||||
When you run `nuxi dev` or `nuxi build`, the following files are generated for IDE type support (and type-checking):
|
||||
When you run `nuxi dev` or `nuxi build`, Nuxt generates the following files for IDE type support (and type-checking):
|
||||
|
||||
### `.nuxt/nuxt.d.ts`
|
||||
|
||||
|
||||
@ -28,7 +28,7 @@ export default defineNuxtPlugin((nuxtApp) => {
|
||||
|
||||
### Server and client startup errors (SSR + SPA)
|
||||
|
||||
Nuxt provides an `app:error` hook that will be called if there are any errors in starting your Nuxt application.
|
||||
Nuxt will call the `app:error` hook if there are any errors in starting your Nuxt application.
|
||||
|
||||
This includes:
|
||||
|
||||
|
||||
@ -7,7 +7,7 @@ head.title: Nuxt directory
|
||||
|
||||
# Nuxt directory
|
||||
|
||||
The `.nuxt/` directory is used by Nuxt in development to generate your Vue application.
|
||||
Nuxt uses the `.nuxt/` directory in development to generate your Vue application.
|
||||
|
||||
::alert{type=warning}
|
||||
You should not touch any files inside since the whole directory will be re-created when running `nuxt dev`.
|
||||
|
||||
@ -41,7 +41,7 @@ export default defineNuxtPlugin(nuxtApp => {
|
||||
|
||||
## Automatically providing helpers
|
||||
|
||||
If you would like to provide a helper on the `NuxtApp` instance, just return it from the plugin under a `provide` key. For example:
|
||||
If you would like to provide a helper on the `NuxtApp` instance, return it from the plugin under a `provide` key. For example:
|
||||
|
||||
```ts
|
||||
export default defineNuxtPlugin(() => {
|
||||
|
||||
@ -6,7 +6,7 @@ head.title: Server directory
|
||||
|
||||
# Server directory
|
||||
|
||||
The server directory is used to create any backend logic for your Nuxt application. It supports HMR and powerful features.
|
||||
Nuxt uses the `server/` directory to create any backend logic for your application. It supports HMR and powerful features.
|
||||
|
||||
The `server/` directory contains API endpoints and server middleware for your project.
|
||||
|
||||
@ -89,7 +89,7 @@ export default async (req: IncomingMessage, res: ServerResponse) => {
|
||||
}
|
||||
```
|
||||
|
||||
To pass the request deeper into the application, you can simply `return` inside the function:
|
||||
To pass the request deeper into the application, you can `return` inside the function:
|
||||
|
||||
```js
|
||||
export default async (req, res) => {
|
||||
@ -102,4 +102,6 @@ export default async (req, res) => {
|
||||
}
|
||||
```
|
||||
|
||||
More information about custom middleware can be found in the documentation for [nuxt.config.js](/docs/directory-structure/nuxt.config#servermiddleware)
|
||||
::alert{type=info icon=🔎}
|
||||
Find more information about custom middleware in the documentation for [nuxt.config.js](/docs/directory-structure/nuxt.config#servermiddleware)
|
||||
::
|
||||
|
||||
@ -14,4 +14,4 @@ Nuxt [automatically generates](/concepts/typescript) a `.nuxt/tsconfig.json` fil
|
||||
}
|
||||
```
|
||||
|
||||
As you need to, you can customize the contents of this file. However, note that if you need to customize your `paths`, this will completely override the auto-generated path aliases. Instead, it is suggested that you add any path aliases you need to the `alias` property within your `nuxt.config`, where they will get picked up and added to the autogenerated `tsconfig`.
|
||||
As you need to, you can customize the contents of this file. However, note that if you need to customize your `paths`, this will override the auto-generated path aliases. Instead, we recommend that you add any path aliases you need to the `alias` property within your `nuxt.config`, where they will get picked up and added to the autogenerated `tsconfig`.
|
||||
|
||||
@ -6,10 +6,10 @@ head.title: Output directory
|
||||
|
||||
# Output directory
|
||||
|
||||
The `.output/` directory is created by Nuxt when building your application for production.
|
||||
Nuxt creates the `.output/` directory when building your application for production.
|
||||
|
||||
::alert{type=warning}
|
||||
You should not touch any files inside since the whole directory will be re-created when running `nuxt build`.
|
||||
::
|
||||
|
||||
This directory is made to be used when deploying your Nuxt application to production. Learn more in our [deployment section](/docs/deployment).
|
||||
Use this directory to deploy your Nuxt application to production. Learn more in our [deployment section](/docs/deployment).
|
||||
|
||||
@ -6,7 +6,7 @@ head.title: Assets directory
|
||||
|
||||
# Assets directory
|
||||
|
||||
The `assets/` directory is used to add all the website assets that will be processed by the build tool (Webpack or Vite).
|
||||
The `assets/` directory is used to add all the website assets that the build tool (Webpack or Vite) will process.
|
||||
|
||||
The directory usually contains the following types of files:
|
||||
|
||||
|
||||
@ -44,7 +44,7 @@ If you have a component in nested directories such as:
|
||||
```
|
||||
|
||||
::alert
|
||||
For clarity, it is recommended that the component's file name matches its name. (So, in the example above, you could rename `Button.vue` to be `BaseFooButton.vue`.)
|
||||
For clarity, we recommend that the component's file name matches its name. (So, in the example above, you could rename `Button.vue` to be `BaseFooButton.vue`.)
|
||||
::
|
||||
|
||||
## Dynamic Imports
|
||||
@ -121,7 +121,7 @@ Use a slot as fallback until `<ClientOnly>` is mounted on client side.
|
||||
|
||||
Making Vue component libraries with automatic tree-shaking and component registration is super easy ✨
|
||||
|
||||
You can use the `components:dirs` hook to easily extend the directory list without requiring user configuration in your Nuxt module.
|
||||
You can use the `components:dirs` hook to extend the directory list without requiring user configuration in your Nuxt module.
|
||||
|
||||
Imagine a directory structure like this:
|
||||
|
||||
|
||||
@ -10,7 +10,7 @@ Nuxt 3 supports `composables/` directory to automatically import your Vue compos
|
||||
|
||||
## How files are scanned
|
||||
|
||||
Only files at the top level of the `composables/` directory (or index files within any subdirectories) will be scanned for composables.
|
||||
Nuxt only scans files at the top level of the `composables/` directory (or index files within any subdirectories) for composables.
|
||||
|
||||
For example:
|
||||
|
||||
|
||||
@ -10,7 +10,7 @@ Nuxt provides a customizable layouts framework you can use throughout your appli
|
||||
|
||||
Layouts are placed in the `layouts/` directory and will be automatically loaded via asynchronous import when used. Layouts are used by setting a `layout` property as part of your page metadata (if you are using the `~/pages` integration), or by using the `<NuxtLayout>` component.
|
||||
|
||||
If you only have a single layout in your application, it is recommended to use [app.vue](/docs/directory-structure/app) instead.
|
||||
If you only have a single layout in your application, we recommend to use [app.vue](/docs/directory-structure/app) instead.
|
||||
|
||||
::alert{type=warning}
|
||||
Unlike other components, your layouts must have a single root element to allow Nuxt to apply transitions between layout changes.
|
||||
|
||||
@ -46,7 +46,7 @@ Unlike, navigation guards in [the vue-router docs](https://router.vuejs.org/guid
|
||||
* `abortNavigation(error)` - rejects the current navigation with an error
|
||||
|
||||
::alert{type=warning}
|
||||
It is advised to use the helper functions above for performing redirects or stopping navigation. Other possible return values described in [the vue-router docs](https://router.vuejs.org/guide/advanced/navigation-guards.html#global-before-guards) may work but there may be breaking changes in future.
|
||||
We recommend to use the helper functions above for performing redirects or stopping navigation. Other possible return values described in [the vue-router docs](https://router.vuejs.org/guide/advanced/navigation-guards.html#global-before-guards) may work but there may be breaking changes in future.
|
||||
::
|
||||
|
||||
## Adding middleware dynamically
|
||||
|
||||
@ -6,4 +6,4 @@ head.title: Node modules directory
|
||||
|
||||
# Node modules directory
|
||||
|
||||
The `node_modules` directory is created by the package manager ([`npm`](https://docs.npmjs.com/cli/v7/commands/npm) or [`yarn`](https://yarnpkg.com/)) to store the dependencies of your project.
|
||||
The package manager ([`npm`](https://docs.npmjs.com/cli/v7/commands/npm) or [`yarn`](https://yarnpkg.com/)) creates the `node_modules` directory to store the dependencies of your project.
|
||||
|
||||
Loading…
Reference in New Issue
Block a user