mirror of
https://github.com/nuxt/nuxt.git
synced 2024-11-11 08:33:53 +00:00
docs: fix and improve multiple sections (#4396)
This commit is contained in:
Damian
GitHub
parent
04a72f83f1
commit
513978e15b
@ -1,6 +1,6 @@
|
||||
<template>
|
||||
<Alert icon="🤖">
|
||||
This section is auto generated from source-code.
|
||||
This section is auto-generated from the source code.
|
||||
</Alert>
|
||||
</template>
|
||||
|
||||
|
||||
@ -1,11 +1,11 @@
|
||||
# Migration Guide
|
||||
|
||||
Already have a Nuxt project to migrate? These migration guides are for users wanting to upgrade their Nuxt application to Nuxt 3 or take a first step in that direction with Nuxt Bridge.
|
||||
Already have a Nuxt project to migrate? These migration guides are for users wanting to upgrade their Nuxt application to Nuxt 3 or take the first step in that direction with Nuxt Bridge.
|
||||
|
||||
- [**From Nuxt 2 to Nuxt 3**](/migration/overview)
|
||||
- [From Nuxt 2 to Nuxt Bridge](/bridge/overview)
|
||||
|
||||
## Feature Comparation
|
||||
## Feature Comparison
|
||||
|
||||
In the table below, there is a quick comparison between 3 versions of Nuxt:
|
||||
|
||||
|
||||
@ -9,7 +9,7 @@ To understand what is Nuxt, we need to understand what we need to create a moder
|
||||
|
||||
- A JavaScript framework to bring reactivity and web components, we chose [Vue.js](https://v3.vuejs.org).
|
||||
- A bundler to support hot module replacement in development and bundle your code for production, we support both [webpack 5](https://webpack.js.org/) and [Vite](https://vitejs.dev/).
|
||||
- A transpiler in order to write the latest JavaScript syntax while supporting legacy browsers, we use [esbuild](https://esbuild.github.io) for that.
|
||||
- A transpiler to write the latest JavaScript syntax while supporting legacy browsers, we use [esbuild](https://esbuild.github.io) for that.
|
||||
- A server for serving your application in development, but also to support [server-side rendering](https://vuejs.org/api/ssr.html#server-side-rendering-api) or API routes, Nuxt uses [h3](https://github.com/unjs/h3) for deployment versatility such as serverless, workers, Node.js and unmatched performance.
|
||||
- A routing library to handle client-side navigation, we chose [vue-router](https://router.vuejs.org/).
|
||||
::
|
||||
@ -33,7 +33,7 @@ Nuxt is composed of different [core packages](https://github.com/nuxt/framework/
|
||||
- Nuxt 2 Bridge: [@nuxt/bridge](https://github.com/nuxt/bridge)
|
||||
::
|
||||
|
||||
We recommend reading each concept to have a full vision of Nuxt capabilities and scope of each package.
|
||||
We recommend reading each concept to have a full vision of Nuxt capabilities and the scope of each package.
|
||||
|
||||
## Are you Nuxt?
|
||||
|
||||
@ -42,9 +42,9 @@ Nuxt is the backbone of your Vue.js project, giving structure to build your proj
|
||||
Extendable with a strong module ecosystem and hooks engine, it makes it easy to connect your REST or GraphQL endpoints, favorite CMS, CSS frameworks and more. PWA and AMP support is only a module away from your Nuxt project.
|
||||
|
||||
::alert{type=info icon=👍}
|
||||
Ready to try? Head over the [Installation section](/getting-started/quick-start).
|
||||
Ready to try? Head over to the [Installation section](/getting-started/quick-start).
|
||||
::
|
||||
|
||||
### Are you *courageously* Nuxt?
|
||||
|
||||
Take a stab at an open [issue](https://github.com/nuxt/framework/issues). This is actually the best way to learn Nuxt, by actually diving into the code. You may even bring an approach or alternative solution that makes Nuxt even better! So, what are you waiting for? Let's go!
|
||||
Take a stab at an open [issue](https://github.com/nuxt/framework/issues). This is the best way to learn Nuxt, by actually diving into the code. You may even bring an approach or alternative solution that makes Nuxt even better! So, what are you waiting for? Let's go!
|
||||
|
||||
@ -1,13 +1,13 @@
|
||||
# Vue.js Development
|
||||
|
||||
Nuxt uses Vue as a frontend framework, and adds features such as components auto-imports and file-based routing. Nuxt 3 integrates Vue 3, the new major release of Vue that enables new patterns for Nuxt users.
|
||||
Nuxt uses Vue as a frontend framework and adds features such as component auto-imports and file-based routing. Nuxt 3 integrates Vue 3, the new major release of Vue that enables new patterns for Nuxt users.
|
||||
|
||||
## Vue.js
|
||||
|
||||
> While an in-depth knowledge of Vue is not required to use Nuxt, we recommend that you read the documentation and go through some of the examples on [vuejs.org](https://vuejs.org/)
|
||||
>
|
||||
|
||||
Nuxt has always used Vue as a frontend framework. We chose to build Nuxt in top of Vue for these reasons:
|
||||
Nuxt has always used Vue as a frontend framework. We chose to build Nuxt on top of Vue for these reasons:
|
||||
|
||||
- The reactivity model of Vue, where a change in data automatically triggers a change in the interface.
|
||||
- The component-based templating, while keeping HTML as the common language of the web, enables intuitive patterns to keep your interface consistent, yet powerful.
|
||||
@ -17,11 +17,11 @@ Nuxt has always used Vue as a frontend framework. We chose to build Nuxt in top
|
||||
|
||||
### Single file components
|
||||
|
||||
[Vue’s single file components](https://v3.vuejs.org/guide/single-file-component.html) (SFC, or `*.vue` files) encapsulate the markup (`<template>`), logic (`<script>`) and styling (`<style>`) of a Vue component. Nuxt provides a zero-config experience for SFCs with [Hot Module Replacement](https://webpack.js.org/concepts/hot-module-replacement/) that offers a seamless developer experience.
|
||||
[Vue’s single-file components](https://v3.vuejs.org/guide/single-file-component.html) (SFC, or `*.vue` files) encapsulate the markup (`<template>`), logic (`<script>`) and styling (`<style>`) of a Vue component. Nuxt provides a zero-config experience for SFCs with [Hot Module Replacement](https://webpack.js.org/concepts/hot-module-replacement/) that offers a seamless developer experience.
|
||||
|
||||
### Components auto-imports
|
||||
|
||||
Every Vue components created in the [`components/` directory](/guide/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.
|
||||
Every Vue component created in the [`components/` directory](/guide/directory-structure/components) of a Nuxt project will be available in your project without having to import it. If a component is not used anywhere, your production’s code will not include it.
|
||||
|
||||
### Vue Router
|
||||
|
||||
@ -32,7 +32,7 @@ Most applications need multiple pages and a way to navigate between them. This i
|
||||
:button-link[Open on StackBlitz]{href="https://stackblitz.com/edit/github-9hzuns?file=app.vue" blank}
|
||||
:button-link[Open on CodeSandbox]{href="https://codesandbox.io/s/nuxt-3-components-auto-import-2xq9z?file=/app.vue" blank}
|
||||
|
||||
The `app.vue` file is the entrypoint, which represents the page displayed in the browser window.
|
||||
The `app.vue` file is the entry point, which represents the page displayed in the browser window.
|
||||
|
||||
Inside the `<template>` of the component, we use the `<Welcome>` component created in the `components/` directory without having to import it.
|
||||
|
||||
@ -56,13 +56,13 @@ Nuxt 3 is based on Vue 3. The new Vue major version introduces several changes t
|
||||
|
||||
### Faster rendering
|
||||
|
||||
Vue Virtual DOM (VDOM) has been rewritten from the ground-up and allows for better rendering performances. On top of that, when working with compiled Single-file components, Vue compiler can further optimize components at build time by separating static and dynamic markup.
|
||||
Vue Virtual DOM (VDOM) has been rewritten from the ground up and allows for better rendering performances. On top of that, when working with compiled Single-file components, the Vue compiler can further optimize components at build time by separating static and dynamic markup.
|
||||
|
||||
This results in faster first rendering (component creation) and updates, and less memory usage. In Nuxt 3, it enables faster server-side rendering as well.
|
||||
|
||||
### 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. Your production bundle will not include them 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, is 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.
|
||||
|
||||
@ -87,7 +87,7 @@ export default {
|
||||
</script>
|
||||
```
|
||||
|
||||
The [Composition API](https://vuejs.org/guide/extras/composition-api-faq.html) introduced in Vue 3 is not a replacement to the Options API, but enables better logic reuse throughout an application, and a more natural way to group code by concerns in complex components.
|
||||
The [Composition API](https://vuejs.org/guide/extras/composition-api-faq.html) introduced in Vue 3 is not a replacement of the Options API, but it enables better logic reuse throughout an application, and is a more natural way to group code by concern in complex components.
|
||||
|
||||
Used with the `setup` keyword in the `<script>` definition, here is the above component rewritten with Composition API and Nuxt 3’s auto-imported Reactivity APIs:
|
||||
|
||||
|
||||
@ -20,7 +20,7 @@ While this technique allows building complex and dynamic UIs with smooth page tr
|
||||
### 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. 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 on 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
|
||||
|
||||
@ -34,7 +34,7 @@ To not lose the benefits of the client-side rendering method, such as dynamic in
|
||||
|
||||
Making a static page interactive in the browser is called "Hydration."
|
||||
|
||||
Universal rendering allows a Nuxt application to provide quick page load times while preserving the benefits of client-side rendering. Furthermore, as the content is already present in the HTML document, crawlers can index it without overheads.
|
||||
Universal rendering allows a Nuxt application to provide quick page load times while preserving the benefits of client-side rendering. Furthermore, as the content is already present in the HTML document, crawlers can index it without overhead.
|
||||
|
||||
{.dark:hidden}
|
||||
{.light:hidden}
|
||||
@ -51,13 +51,13 @@ Universal rendering allows a Nuxt application to provide quick page load times w
|
||||
|
||||
### Examples
|
||||
|
||||
Universal rendering is very versatile and can fit almost any use-case, and is especially appropriate for any content-oriented websites: **blog, marketing websites, portfolio, E-commerce, Marketplaces.**
|
||||
Universal rendering is very versatile and can fit almost any use case, and is especially appropriate for any content-oriented websites: **blogs, marketing websites, portfolios, e-commerce sites, and marketplaces.**
|
||||
|
||||
## Summary
|
||||
|
||||
Client-side and universal rendering are different strategies to display an interface in a browser.
|
||||
|
||||
By default, Nuxt uses **universal rendering** to provide a better User experience, performance and optimize search engine indexation, but you can switch rendering modes in [one line of configuration](/guide/directory-structure/nuxt.config#ssr).
|
||||
By default, Nuxt uses **universal rendering** to provide better user experience and performance, and to optimize search engine indexing, but you can switch rendering modes in [one line of configuration](/guide/directory-structure/nuxt.config#ssr).
|
||||
|
||||
## Coming in Nuxt 3
|
||||
|
||||
|
||||
@ -6,7 +6,7 @@ Contrary to a classic global declaration, Nuxt preserves typings and IDEs comple
|
||||
|
||||
::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.
|
||||
You can find a reference of auto-imported [composables](/api/composables/use-async-data) and [utilities](/api/utils/$fetch) in the API section.
|
||||
You can find a reference for auto-imported [composables](/api/composables/use-async-data) and [utilities](/api/utils/$fetch) in the API section.
|
||||
::
|
||||
|
||||
::alert{type=warning}
|
||||
@ -36,7 +36,7 @@ Vue 3 exposes Reactivity APIs like `ref` or `computed`, as well as lifecycle hoo
|
||||
</script>
|
||||
```
|
||||
|
||||
## Directory based auto-imports
|
||||
## Directory-based auto-imports
|
||||
|
||||
Nuxt directly auto-imports files created in defined directories:
|
||||
|
||||
|
||||
@ -50,11 +50,11 @@ 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 and requires part of Nuxt core to be involved by 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 is fragile and prone to breakage and not suitable for serverless and service-worker environments.
|
||||
|
||||
Nuxt 3 generates this dist when running `nuxt build` into a [`.output`](/guide/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 your static files, making it a true hybrid framework for the JAMstack. In addition, Nuxt implements a native storage layer, supporting multi source, drivers and local assets.
|
||||
The output contains runtime code to run your Nuxt server in any environment (including experimental browser service workers!) and serve your static files, making it a true hybrid framework for the JAMstack. In addition, Nuxt implements a native storage layer, supporting multi-source drivers and local assets.
|
||||
|
||||
::alert{type="info" icon=IconCode}
|
||||
Check out the Nitro engine on GitHub: [unjs/nitro](https://github.com/unjs/nitro).
|
||||
|
||||
@ -1,6 +1,6 @@
|
||||
# Modules
|
||||
|
||||
Nuxt provides a module system to extend the framework core and simplify integrations. You don't need to develop everything from scratch nor maintain boilerplate if there is already a Nuxt module for it. Adding Nuxt modules is possible using [`nuxt.config`](/api/configuration/nuxt.config#modules).
|
||||
Nuxt provides a module system to extend the framework core and simplify integrations. You don't need to develop everything from scratch or maintain boilerplate if there is already a Nuxt module for it. Adding Nuxt modules is possible using [`nuxt.config`](/api/configuration/nuxt.config#modules).
|
||||
|
||||
## Exploring Nuxt Modules
|
||||
|
||||
|
||||
@ -1,6 +1,6 @@
|
||||
# Head Management
|
||||
|
||||
Out-of-the-box, Nuxt provides good default values for `charset` and `viewport` meta tags, but you can override these if you need to, as well as customizing other meta tags for your site in several different ways.
|
||||
Out-of-the-box, Nuxt provides good default values for `charset` and `viewport` meta tags, but you can override these if you need to, as well as customize other meta tags for your site in several different ways.
|
||||
|
||||
:ReadMore{link="/api/configuration/nuxt.config#head"}
|
||||
|
||||
@ -81,7 +81,7 @@ definePageMeta({
|
||||
</script>
|
||||
```
|
||||
|
||||
And then in your layout file you might use the route metadata you've previously set:
|
||||
And then in your layout file, you might use the route's metadata you have previously set:
|
||||
|
||||
```vue{}[layouts/default.vue]
|
||||
<script setup>
|
||||
|
||||
@ -174,7 +174,7 @@ When we call `fetch` in the browser, user headers like `cookie` will be directly
|
||||
::ReadMore{link="/api/utils/$fetch"}
|
||||
::
|
||||
|
||||
### Example: Bypass API headers to client
|
||||
### Example: Pass client headers to the API
|
||||
|
||||
We can use [`useRequestHeaders`](/api/composables/use-request-headers) to access and proxy cookies to the API from server-side.
|
||||
|
||||
|
||||
@ -12,7 +12,7 @@ Nuxt 3 is a full-stack framework, which means there are several sources of unpre
|
||||
|
||||
You can hook into Vue errors using [`onErrorCaptured`](https://vuejs.org/api/composition-api-lifecycle.html#onerrorcaptured).
|
||||
|
||||
In addition, Nuxt provides a `vue:error` hook that will be called if there are any errors that propagate up to the top level.
|
||||
In addition, Nuxt provides a `vue:error` hook that will be called if any errors propagate up to the top level.
|
||||
|
||||
If you are using a error reporting framework, you can provide a global handler through [`vueApp.config.errorHandler`](https://vuejs.org/api/application.html#app-config-errorhandler). It will receive all Vue errors, even if they are handled.
|
||||
|
||||
|
||||
@ -59,7 +59,7 @@ If you are using [app.vue](/guide/directory-structure/app), make sure to use the
|
||||
|
||||
Pages **must have a single root element** to allow route transitions between pages. (HTML comments are considered elements as well.)
|
||||
|
||||
This means that when the route is server rendered, or statically generated, you will be able to see its contents correctly, but when you navigate towards that route during client side navigation the transition between routes will fail and you'll see that the route will not be rendered.
|
||||
This means that when the route is server-rendered, or statically generated, you will be able to see its contents correctly, but when you navigate towards that route during client-side navigation the transition between routes will fail and you'll see that the route will not be rendered.
|
||||
|
||||
Here are some examples to illustrate what a page with a single root element looks like:
|
||||
|
||||
@ -259,7 +259,7 @@ Of course, you are welcome to define metadata for your own use throughout your a
|
||||
|
||||
#### `keepalive`
|
||||
|
||||
Nuxt will automatically wrap your page in [the Vue `<KeepAlive>` component](https://vuejs.org/guide/built-ins/keep-alive.html#keepalive) if you set `keepalive: true` in your `definePageMeta`. This might be useful to do, for example, in a parent route which has dynamic child routes, if you want to preserve page state across route changes. You can also set props to be passed to `<KeepAlive>` (see a full list [here](https://vuejs.org/api/built-in-components.html#keepalive)).
|
||||
Nuxt will automatically wrap your page in [the Vue `<KeepAlive>` component](https://vuejs.org/guide/built-ins/keep-alive.html#keepalive) if you set `keepalive: true` in your `definePageMeta`. This might be useful to do, for example, in a parent route that has dynamic child routes, if you want to preserve page state across route changes. You can also set props to be passed to `<KeepAlive>` (see a full list [here](https://vuejs.org/api/built-in-components.html#keepalive)).
|
||||
|
||||
#### `key`
|
||||
|
||||
@ -275,11 +275,11 @@ You can define middleware to apply before loading this page. It will be merged w
|
||||
|
||||
#### `layoutTransition` and `pageTransition`
|
||||
|
||||
You can define transition properties for the `<transition>` components that wraps your pages and layouts, or pass `false` to disable the `<transition>` wrapper for that route. You can see a list of options that can be passed [here](https://vuejs.org/api/built-in-components.html#transition) or read [more about how transitions work](https://vuejs.org/guide/built-ins/transition.html#transition).
|
||||
You can define transition properties for the `<transition>` component that wraps your pages and layouts, or pass `false` to disable the `<transition>` wrapper for that route. You can see a list of options that can be passed [here](https://vuejs.org/api/built-in-components.html#transition) or read [more about how transitions work](https://vuejs.org/guide/built-ins/transition.html#transition).
|
||||
|
||||
#### `alias`
|
||||
|
||||
You can define page aliases. They allow you to access the same page from different paths. It can be either a string or an array of string as defined [here](https://router.vuejs.org/guide/essentials/redirect-and-alias.html#alias) on vue-router documentation.
|
||||
You can define page aliases. They allow you to access the same page from different paths. It can be either a string or an array of strings as defined [here](https://router.vuejs.org/guide/essentials/redirect-and-alias.html#alias) on vue-router documentation.
|
||||
|
||||
## Navigation
|
||||
|
||||
@ -303,11 +303,11 @@ Learn more about [`<NuxtLink>`](/api/components/nuxt-link) usage.
|
||||
|
||||
It is possible to set default [vue-router options](https://router.vuejs.org/api/#routeroptions).
|
||||
|
||||
**Note:** `history` and `routes` options will be always overriden by Nuxt.
|
||||
**Note:** `history` and `routes` options will be always overridden by Nuxt.
|
||||
|
||||
### Using `app/router.options`
|
||||
|
||||
This is the recommaned way to specify router options.
|
||||
This is the recommended way to specify router options.
|
||||
|
||||
```js [app/router.options.ts]
|
||||
import type { RouterConfig } from '@nuxt/schema'
|
||||
|
||||
@ -102,7 +102,7 @@ If you want to use Vue plugins, like [vue-gtag](https://github.com/MatteoGabriel
|
||||
|
||||
> There is an Open RFC to make this even easier! See [nuxt/framework#1175](https://github.com/nuxt/framework/discussions/1175)
|
||||
|
||||
First install the plugin you want.
|
||||
First, install the plugin you want.
|
||||
|
||||
```bash
|
||||
yarn add --dev vue-gtag-next
|
||||
|
||||
@ -6,7 +6,7 @@ head.title: Public directory
|
||||
|
||||
# Public directory
|
||||
|
||||
The `public/` directory is directly served at server root and contains public files that have to keep their names (e.g. `robots.txt`) _or_ likely won't change (e.g. `favicon.ico`).
|
||||
The `public/` directory is directly served at the server root and contains public files that have to keep their names (e.g. `robots.txt`) _or_ likely won't change (e.g. `favicon.ico`).
|
||||
|
||||
::alert{icon=💡}
|
||||
This is known as the [`static/`](https://nuxtjs.org/docs/directory-structure/static) directory in Nuxt 2.
|
||||
|
||||
@ -4,4 +4,6 @@ title: server
|
||||
head.title: Server directory
|
||||
---
|
||||
|
||||
# Server directory
|
||||
|
||||
::ReadMore{link="/guide/features/server-routes"}
|
||||
|
||||
@ -37,7 +37,7 @@ Since Nuxt 3 uses [`<Suspense>`](https://vuejs.org/guide/built-ins/suspense.html
|
||||
::
|
||||
|
||||
::alert{type=warning}
|
||||
Remember that `app.vue` acts as the main component of your Nuxt application. Anything you add in it (JS and CSS) will be global and included in every page.
|
||||
Remember that `app.vue` acts as the main component of your Nuxt application. Anything you add to it (JS and CSS) will be global and included in every page.
|
||||
::
|
||||
|
||||
If you want to have the possibility to customize the structure around the page between pages, check out the [`layouts/`](/guide/directory-structure/layouts) directory.
|
||||
|
||||
@ -28,4 +28,4 @@ middleware/foo/*.js
|
||||
!middleware/foo/bar.js
|
||||
```
|
||||
|
||||
> More details about the spec are in [gitignore doc](https://git-scm.com/docs/gitignore)
|
||||
> More details about the spec are in the [gitignore doc](https://git-scm.com/docs/gitignore).
|
||||
|
||||
@ -16,7 +16,7 @@ export default defineNuxtConfig({
|
||||
})
|
||||
```
|
||||
|
||||
To ensure your configuration is up to date, nuxt will make a full restart when detecting changes in the nuxt main configuration file, the `.env`, `.nuxtignore` and `.nuxtrc` dot files.
|
||||
To ensure your configuration is up to date, nuxt will make a full restart when detecting changes in the nuxt main configuration file, the `.env`, `.nuxtignore` and `.nuxtrc` dotfiles.
|
||||
|
||||
::ReadMore{link="/api/configuration/nuxt.config"}
|
||||
::
|
||||
|
||||
@ -6,7 +6,7 @@ head.title: Assets directory
|
||||
|
||||
# Assets directory
|
||||
|
||||
The `assets/` directory is used to add all the website assets that the build tool (webpack or Vite) will process.
|
||||
The `assets/` directory is used to add all the website's 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, 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`.)
|
||||
For clarity, we recommend that the component's filename matches its name. (So, in the example above, you could rename `Button.vue` to be `BaseFooButton.vue`.)
|
||||
::
|
||||
|
||||
## Dynamic components
|
||||
@ -209,7 +209,7 @@ export default defineNuxtModule({
|
||||
})
|
||||
```
|
||||
|
||||
That's it! Now in your project, you can import your ui library as a Nuxt module in your `nuxt.config` file:
|
||||
That's it! Now in your project, you can import your UI library as a Nuxt module in your `nuxt.config` file:
|
||||
|
||||
```js
|
||||
export default {
|
||||
|
||||
@ -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, we recommend to use [app.vue](/guide/directory-structure/app) instead.
|
||||
If you only have a single layout in your application, we recommend using [app.vue](/guide/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 - and this root element cannot be a `<slot />`.
|
||||
|
||||
@ -35,7 +35,7 @@ export default defineNuxtRouteMiddleware((to, from) => {
|
||||
|
||||
Nuxt provides two globally available helpers that can be returned directly from the middleware:
|
||||
|
||||
1. `navigateTo (route: string | Route)` - Redirects to the given route, within plugins or middleware. It can also be called directly on client side to perform a page navigation.
|
||||
1. `navigateTo (route: string | Route)` - Redirects to the given route, within plugins or middleware. It can also be called directly on the client side to perform page navigation.
|
||||
2. `abortNavigation (err?: string | Error)` - Aborts the navigation, with an optional error message.
|
||||
|
||||
Unlike, navigation guards in [the vue-router docs](https://router.vuejs.org/guide/advanced/navigation-guards.html#global-before-guards), a third `next()` argument is not passed, and redirects or route cancellation is handled by returning a value from the middleware. Possible return values are:
|
||||
@ -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}
|
||||
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.
|
||||
We recommend using 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
|
||||
|
||||
@ -9,7 +9,7 @@ How to deploy Nuxt to Cloudflare Workers.
|
||||
::list
|
||||
|
||||
- Support for Workers build output
|
||||
- Zero millisecond cold start with edge-side rendering
|
||||
- Zero-millisecond cold start with edge-side rendering
|
||||
- Minimal configuration required
|
||||
::
|
||||
|
||||
|
||||
@ -16,11 +16,11 @@ How to deploy Nuxt to Firebase Hosting.
|
||||
|
||||
Nitro supports [Firebase Hosting](https://firebase.google.com/docs/hosting) with Cloud Functions out of the box.
|
||||
|
||||
**Note**: You will need to be on the **Blaze plan** to use Nitro with Cloud Functions.
|
||||
**Note**: You need to be on the **Blaze plan** to use Nitro with Cloud Functions.
|
||||
|
||||
### Using Nitro
|
||||
|
||||
If you don't already have a `firebase.json` in your root directory, Nitro will create one the first time you run it. All you will need to do is edit this to replace `<your_project_id>` with the project ID that you have chosen on Firebase.
|
||||
If you don't already have a `firebase.json` in your root directory, Nitro will create one the first time you run it. In this file, you will need to replace `<your_project_id>` with the ID of your Firebase project.
|
||||
|
||||
This file should then be committed to version control. You can also create a `.firebaserc` file if you don't want to manually pass your project ID to your `firebase` commands (with `--project <your_project_id>`):
|
||||
|
||||
|
||||
@ -9,7 +9,7 @@ How to deploy Nuxt to a Node.js hosting using PM2.
|
||||
::list
|
||||
|
||||
- Support for ultra-minimal SSR build
|
||||
- Zero millisecond cold start
|
||||
- Zero-millisecond cold start
|
||||
- More configuration required
|
||||
::
|
||||
|
||||
@ -28,7 +28,7 @@ export default {
|
||||
|
||||
## Deployment
|
||||
|
||||
After running `yarn build`, all the required files are located in the `.output` folder. Static assets are in the `public` subdirectory and the server with its dependencies are within the `server` subdirectory.
|
||||
After running `yarn build`, all the required files are located in the `.output` folder. Static assets are in the `public` subdirectory and the server with its dependencies is within the `server` subdirectory.
|
||||
|
||||
This `.output` folder can be deployed to your Node.js host and the server can be run using [`pm2`](https://pm2.keymetrics.io/docs/usage/quick-start/).
|
||||
|
||||
|
||||
@ -30,7 +30,7 @@ export default {
|
||||
|
||||
### Reusable preset
|
||||
|
||||
You can also define a preset in a separate file (or publish as a separate npm package).
|
||||
You can also define a preset in a separate file (or publish it as a separate npm package).
|
||||
|
||||
```ts [my-preset/index.ts]
|
||||
import type { NitroPreset } from 'nitropack'
|
||||
|
||||
@ -28,7 +28,7 @@ NITRO_PRESET=lambda npx nuxt build
|
||||
AWS Lambda [defaults to payload version v2](https://docs.aws.amazon.com/apigateway/latest/developerguide/http-api-develop-integrations-lambda.html). This Nitro preset supports both v1 and v2 payloads.
|
||||
::
|
||||
|
||||
### Entrypoint
|
||||
### Entry point
|
||||
|
||||
When running `nuxt build` with the Lambda preset, the result will be an entry point that exports a handler function that responds to an event and returns a response.
|
||||
|
||||
|
||||
@ -52,7 +52,7 @@ This preset will respect the following runtime environment variables:
|
||||
|
||||
- `NUXT_PORT` or `PORT` (defaults to `3000`)
|
||||
- `NUXT_HOST` or `HOST` (defaults to `'localhost'`)
|
||||
- `NITRO_SSL_CERT` and `NITRO_SSL_KEY` - if both are present, this will launch the server in HTTPS mode. In the vast majority of cases this should not be used other than for testing, and the Nitro server should be run behind a reverse proxy like nginx or Cloudflare which terminates SSL.
|
||||
- `NITRO_SSL_CERT` and `NITRO_SSL_KEY` - if both are present, this will launch the server in HTTPS mode. In the vast majority of cases, this should not be used other than for testing, and the Nitro server should be run behind a reverse proxy like nginx or Cloudflare which terminates SSL.
|
||||
|
||||
## Server timings
|
||||
|
||||
|
||||
@ -14,7 +14,7 @@ Back to [presets list](/guide/deployment/presets).
|
||||
::
|
||||
|
||||
::alert{type=warning}
|
||||
Deployment as service worker has some limitations since SSR code is not running in Node.js environment but pure JavaScript.
|
||||
Deployment as a service worker has some limitations since SSR code is not running in Node.js environment but pure JavaScript.
|
||||
::
|
||||
|
||||
## Usage
|
||||
@ -39,4 +39,4 @@ NITRO_PRESET=worker npx nuxt build
|
||||
|
||||
The worker preset produces a service worker that can provide full HTML rendering within a worker context (for example [Cloudflare Workers](/guide/deployment/cloudflare)). It registers appropriate handlers for `fetch`, `install` and `activate`.
|
||||
|
||||
For more information you can see the [source code](https://github.com/unjs/nitro/blob/main/src/presets/service-worker.ts).
|
||||
For more information, you can check out the [source code](https://github.com/unjs/nitro/blob/main/src/presets/service-worker.ts).
|
||||
|
||||
@ -18,12 +18,12 @@ For more details, check out [the source code](https://github.com/nuxt/framework/
|
||||
|
||||
## The NuxtApp interface
|
||||
|
||||
When rendering a page in Browser or server-side, a shared context will be created, referred to as `nuxtApp`.
|
||||
When rendering a page in the browser or on the server, a shared context will be created, referred to as `nuxtApp`.
|
||||
This context keeps vue instance, runtime hooks, and internal states like ssrContext and payload for hydration.
|
||||
You can think of it as **Runtime Core**.
|
||||
|
||||
This context can be accessed using `useNuxtApp()` composable within nuxt plugins and `<script setup>` and vue composables.
|
||||
Global usage is only possible for Browser but not possible on the server-side to avoid sharing context between users.
|
||||
Global usage is possible for the browser but not on the server, to avoid sharing context between users.
|
||||
|
||||
To extend the `nuxtApp` interface and hook into different stages or access contexts, we can use [Nuxt Plugins](/guide/directory-structure/plugins).
|
||||
|
||||
@ -73,5 +73,5 @@ While both areas can be extended, that runtime context is isolated from build-ti
|
||||
|
||||
`nuxt.config` and [Nuxt Modules](/guide/going-further/modules) can be used to extend the build context, and [Nuxt Plugins](/guide/directory-structure/plugins) can be used to extend runtime.
|
||||
|
||||
When building an application for production `nuxi build` will generate a standalone build
|
||||
When building an application for production, `nuxi build` will generate a standalone build
|
||||
in the `.output` directory, independent of `nuxt.config` and [Nuxt modules](/guide/going-further/modules).
|
||||
|
||||
@ -4,7 +4,7 @@ Nuxt provides a powerful hooking system to expand almost every aspect using hook
|
||||
|
||||
## Nuxt Hooks (build time)
|
||||
|
||||
This hooks are available for [Nuxt Modules](/guide/going-further/modules) and build context.
|
||||
These hooks are available for [Nuxt Modules](/guide/going-further/modules) and build context.
|
||||
|
||||
### Usage with `nuxt.config`
|
||||
|
||||
|
||||
@ -1,7 +1,7 @@
|
||||
# Module Author Guide
|
||||
|
||||
Nuxt provides a zero-config experience with a preset of integrations and best practices to develop Web applications.
|
||||
A powerful configuration and hooks system makes it possible to customize almost every aspect of Nuxt Framework and add endless possible integrations when it comes to customization. You can learn more about how nuxt works in [Nuxt internals](/guide/going-further/internals) section.
|
||||
A powerful configuration and hooks system makes it possible to customize almost every aspect of Nuxt Framework and add endless possible integrations when it comes to customization. You can learn more about how nuxt works in the [Nuxt internals](/guide/going-further/internals) section.
|
||||
|
||||
Nuxt exposes a powerful API called **Nuxt Modules**. Nuxt modules are simple async functions that sequentially run when starting nuxt in development mode using `nuxi dev` or building a project for production with `nuxi build`.
|
||||
Using Nuxt Modules, we can encapsulate, properly test and share custom solutions as npm packages without adding unnecessary boilerplate to the Nuxt project itself.
|
||||
@ -95,7 +95,7 @@ export default defineNuxtModule({
|
||||
})
|
||||
```
|
||||
|
||||
Result of `defineNuxtModule` is a wrapper function with `(inlineOptions, nuxt)` signature. It applies defaults and other necessary steps and calls the`setup` function when called.
|
||||
The result of `defineNuxtModule` is a wrapper function with an `(inlineOptions, nuxt)` signature. It applies defaults and other necessary steps and calls the `setup` function when called.
|
||||
|
||||
**`defineNuxtModule` features:**
|
||||
|
||||
@ -104,7 +104,7 @@ Result of `defineNuxtModule` is a wrapper function with `(inlineOptions, nuxt)`
|
||||
- Support `defaults` and `meta.configKey` for automatically merging module options
|
||||
- Type hints and automated type inference
|
||||
- Add shims for basic Nuxt 2 compatibility
|
||||
- Ensure module get's installed only once using a unique key computed from `meta.name` or `meta.configKey`
|
||||
- Ensure module gets installed only once using a unique key computed from `meta.name` or `meta.configKey`
|
||||
- Automatically register Nuxt hooks
|
||||
- Automatically check for compatibility issues based on module meta
|
||||
- Expose `getOptions` and `getMeta` for internal usage of Nuxt
|
||||
|
||||
@ -6,7 +6,7 @@
|
||||
|
||||
### Install dependency
|
||||
|
||||
You can install the latest nuxt kit by adding it to `dependencies` of `package.json`. However, please consider always explicitly installing the `@nuxt/kit` package even if it is already installed by nuxt.
|
||||
You can install the latest nuxt kit by adding it to the `dependencies` section of your `package.json`. However, please consider always explicitly installing the `@nuxt/kit` package even if it is already installed by nuxt.
|
||||
|
||||
```json [package.json]
|
||||
{
|
||||
|
||||
@ -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 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:
|
||||
|
||||
@ -114,7 +114,7 @@ If you encounter these errors, the issue is almost certainly with the upstream l
|
||||
|
||||
### Transpiling libraries
|
||||
|
||||
In the mean-time, you can tell Nuxt not to try to import these libraries by adding them to `build.transpile`:
|
||||
In the meantime, you can tell Nuxt not to try to import these libraries by adding them to `build.transpile`:
|
||||
|
||||
```js
|
||||
import { defineNuxtConfig } from 'nuxt3'
|
||||
@ -169,7 +169,7 @@ import pkg from 'cjs-pkg'
|
||||
console.log(pkg) // { test: 123 }
|
||||
```
|
||||
|
||||
However, because of complexities for syntax detection and different bundle formats, there is always a chance that interop default fails and we end up with something like this:
|
||||
However, because of the complexities of syntax detection and different bundle formats, there is always a chance that the interop default fails and we end up with something like this:
|
||||
|
||||
```js
|
||||
import pkg from 'cjs-pkg'
|
||||
@ -210,7 +210,7 @@ The good news is that it's relatively simple to fix issues of ESM compatibility.
|
||||
|
||||
1. **You can rename your ESM files to end with `.mjs`.**
|
||||
|
||||
_This is the recommended and simplest approach._ You may have to sort out issues with your library's dependencies, and possibly with your build system, but in most cases this should fix the problem for you. It's also recommended to rename your CJS files to end with `.cjs`, for the greatest explicitness.
|
||||
_This is the recommended and simplest approach._ You may have to sort out issues with your library's dependencies and possibly with your build system, but in most cases, this should fix the problem for you. It's also recommended to rename your CJS files to end with `.cjs`, for the greatest explicitness.
|
||||
|
||||
1. **You can opt to make your entire library ESM-only**.
|
||||
|
||||
|
||||
@ -18,7 +18,7 @@ function useMyComposable () {
|
||||
Plugins also receive `nuxtApp` as the first argument for convenience. [Read more about plugins.](/docs/directory-structure/plugins)
|
||||
|
||||
::alert{icon=👉}
|
||||
**`useNuxtApp` (on server side) only works during `setup`, inside Nuxt plugins or `Lifecycle Hooks`**.
|
||||
**`useNuxtApp` (on the server) only works during `setup`, inside Nuxt plugins or `Lifecycle Hooks`**.
|
||||
::
|
||||
|
||||
## Providing helpers
|
||||
|
||||
@ -1,7 +1,7 @@
|
||||
# Testing
|
||||
|
||||
::alert{icon=👉}
|
||||
Test utils are still in development and the API and behavior may change. Currently it's for module authors to preview but not yet ready for testing production apps.
|
||||
Test utils are still in development and the API and behavior may change. Currently, it's for module authors to preview but not yet ready for testing production apps.
|
||||
::
|
||||
|
||||
In Nuxt 3, we have a rewritten version of `@nuxt/test-utils` available as `@nuxt/test-utils-edge`. We support [Vitest](https://github.com/vitest-dev/vitest) and [Jest](https://jestjs.io/) as the test runner.
|
||||
@ -14,7 +14,7 @@ yarn add --dev @nuxt/test-utils-edge vitest
|
||||
|
||||
## Setup
|
||||
|
||||
In each describe block where you are taking advantage of the `@nuxt/test-utils` helper methods, you will need to set up the test context before beginning.
|
||||
In each `describe` block where you are taking advantage of the `@nuxt/test-utils` helper methods, you will need to set up the test context before beginning.
|
||||
|
||||
```ts
|
||||
import { describe, test } from 'vitest'
|
||||
@ -31,7 +31,7 @@ describe('My test', () => {
|
||||
})
|
||||
```
|
||||
|
||||
Behind the scenes, `setup` performs a number of tasks in `beforeAll`, `beforeEach`, `afterEach` and `afterAll` to setup the Nuxt test environment correctly.
|
||||
Behind the scenes, `setup` performs a number of tasks in `beforeAll`, `beforeEach`, `afterEach` and `afterAll` to set up the Nuxt test environment correctly.
|
||||
|
||||
## Options
|
||||
|
||||
@ -99,7 +99,7 @@ Under the hood, Nuxt test utils uses [`playwright`](https://playwright.dev/) to
|
||||
|
||||
#### `runner`
|
||||
|
||||
Specify the runner for the test suite. Currently [Vitest](https://vitest.dev/) is recommend.
|
||||
Specify the runner for the test suite. Currently, [Vitest](https://vitest.dev/) is recommended.
|
||||
|
||||
* Type: `'vitest' | 'jest'`
|
||||
* Default: `'vitest'`
|
||||
@ -144,7 +144,7 @@ const pageUrl = url('/page')
|
||||
|
||||
### Fixture Setup
|
||||
|
||||
To test the modules we create, we could setup some Nuxt apps as fixtures and test their behaviors. For example, we can create a simple Nuxt app under `./test/fixture` with the configuration like:
|
||||
To test the modules we create, we could set up some Nuxt apps as fixtures and test their behaviors. For example, we can create a simple Nuxt app under `./test/fixture` with the configuration like:
|
||||
|
||||
```ts
|
||||
// nuxt.config.js
|
||||
@ -181,7 +181,7 @@ describe('ssr', async () => {
|
||||
})
|
||||
```
|
||||
|
||||
For more usage, please reference to our [tests for Nuxt 3 framework](https://github.com/nuxt/framework/blob/main/test/basic.test.ts).
|
||||
For more usage, please refer to our [tests for Nuxt 3 framework](https://github.com/nuxt/framework/blob/main/test/basic.test.ts).
|
||||
|
||||
## Testing in a browser
|
||||
|
||||
|
||||
@ -36,10 +36,10 @@ type DataT = {
|
||||
* **options**:
|
||||
* _lazy_: whether to resolve the async function after loading the route, instead of blocking navigation (defaults to `false`)
|
||||
* _default_: a factory function to set the default value of the data, before the async function resolves - particularly useful with the `lazy: true` option
|
||||
* _server_: whether to fetch the data on server-side (defaults to `true`)
|
||||
* _server_: whether to fetch the data on the server (defaults to `true`)
|
||||
* _transform_: a function that can be used to alter `handler` function result after resolving
|
||||
* _pick_: only pick specified keys in this array from `handler` function result
|
||||
* _watch_: watch reactive sources to auto refresh
|
||||
* _pick_: only pick specified keys in this array from the `handler` function result
|
||||
* _watch_: watch reactive sources to auto-refresh
|
||||
* _initialCache_: When set to `false`, will skip payload cache for initial fetch. (defaults to `true`)
|
||||
* _default_: A function that returns the default value (before the handler function returns its value).
|
||||
|
||||
|
||||
@ -92,7 +92,7 @@ the server in the future if the browser does not have an HTTPS connection. This
|
||||
### `domain`
|
||||
|
||||
Specifies the value for the [`Domain` `Set-Cookie` attribute](https://tools.ietf.org/html/rfc6265#section-5.2.3). By default, no
|
||||
domain is set, and most clients will consider to apply the cookie only to the current domain.
|
||||
domain is set, and most clients will consider applying the cookie only to the current domain.
|
||||
|
||||
### `path`
|
||||
|
||||
|
||||
@ -8,7 +8,7 @@ This function will return the global Nuxt error that is being handled.
|
||||
const error = useError()
|
||||
```
|
||||
|
||||
`useError` set an error in state, create a reactive and SSR-friendly global Nuxt error across components.
|
||||
`useError` sets an error in the state and creates a reactive and SSR-friendly global Nuxt error across components.
|
||||
|
||||
::ReadMore{link="/guide/features/error-handling"}
|
||||
::
|
||||
|
||||
@ -40,9 +40,9 @@ type DataT = {
|
||||
* `baseURL`: Base URL for the request
|
||||
* **Options (from `useAsyncData`)**:
|
||||
* `lazy`: Whether to resolve the async function after loading the route, instead of blocking navigation (defaults to `false`).
|
||||
* `server`: Whether to fetch the data on server-side (defaults to `true`).
|
||||
* `server`: Whether to fetch the data on the server (defaults to `true`).
|
||||
* `default`: A factory function to set the default value of the data, before the async function resolves - particularly useful with the `lazy: true` option.
|
||||
* `pick`: Only pick specified keys in this array from `handler` function result.
|
||||
* `pick`: Only pick specified keys in this array from the `handler` function result.
|
||||
* `transform`: A function that can be used to alter `handler` function result after resolving.
|
||||
|
||||
## Return values
|
||||
|
||||
@ -21,7 +21,7 @@ By default, [useAsyncData](/api/composables/use-async-data) blocks navigation un
|
||||
|
||||
<script setup>
|
||||
/* Navigation will occur before fetching is complete.
|
||||
Handle pending and error state directly within your component's template
|
||||
Handle pending and error states directly within your component's template
|
||||
*/
|
||||
const { pending, data: count } = useLazyAsyncData('count', () => $fetch('/api/count'))
|
||||
|
||||
|
||||
@ -26,7 +26,7 @@ By default, [useFetch](/api/composables/use-fetch) blocks navigation until its a
|
||||
|
||||
<script setup>
|
||||
/* Navigation will occur before fetching is complete.
|
||||
Handle pending and error state directly within your component's template
|
||||
Handle pending and error states directly within your component's template
|
||||
*/
|
||||
const { pending, data: posts } = useLazyFetch('/api/posts')
|
||||
watch(posts, (newPosts) => {
|
||||
|
||||
@ -13,5 +13,5 @@ const headers = useRequestHeaders(['cookie'])
|
||||
```
|
||||
|
||||
::alert{icon=👉}
|
||||
On client side, `useRequestHeaders` will return an empty object.
|
||||
In the browser, `useRequestHeaders` will return an empty object.
|
||||
::
|
||||
|
||||
@ -4,8 +4,8 @@
|
||||
useState<T>(key: string, init?: () => T | Ref<T>): Ref<T>
|
||||
```
|
||||
|
||||
* **key**: A unique key ensuring that data fetching can be properly de-duplicated across requests
|
||||
* **init**: A function that provides initial value for the state when it's not initiated. This function can also return a `Ref`.
|
||||
* **key**: A unique key ensuring that data fetching is properly de-duplicated across requests
|
||||
* **init**: A function that provides initial value for the state when not initiated. This function can also return a `Ref`.
|
||||
* **T**: (typescript only) Specify the type of state
|
||||
|
||||
::ReadMore{link="/guide/features/state-management"}
|
||||
|
||||
@ -83,7 +83,7 @@ In this example, we use `<NuxtLink>` with `target`, `rel`, and `noRel` props.
|
||||
- **external**: Forces the link to be considered as external (`true`) or internal (`false`). This is helpful to handle edge-cases
|
||||
|
||||
::alert{icon=👉}
|
||||
Defaults can be overwriten, see [overwriting defaults](#overwriting-defaults) if you want to change them.
|
||||
Defaults can be overwritten, see [overwriting defaults](#overwriting-defaults) if you want to change them.
|
||||
::
|
||||
|
||||
## Overwriting defaults
|
||||
|
||||
@ -3,7 +3,7 @@
|
||||
::ReadMore{link="/guide/features/data-fetching"}
|
||||
::
|
||||
|
||||
Nuxt uses [ohmyfetch](https://github.com/unjs/ohmyfetch) to expose globally the `$fetch` helper for making HTTP requests within you Vue app or API routes.
|
||||
Nuxt uses [ohmyfetch](https://github.com/unjs/ohmyfetch) to expose globally the `$fetch` helper for making HTTP requests within your Vue app or API routes.
|
||||
|
||||
During server-side rendering, calling `$fetch` to fetch your internal [API routes](/guide/directory-structure/server) will directly call the relevant function (emulating the request), **saving an additional API call**.
|
||||
|
||||
|
||||
@ -9,4 +9,4 @@ refreshNuxtData(keys?: string | string[])
|
||||
|
||||
Available options:
|
||||
|
||||
* `keys`: Provides an array of keys that used in `useAsyncData` to refetch. When it's not specified, all `useAsyncData` and `useFetch` will be refetched.
|
||||
* `keys`: Provides an array of keys that are used in `useAsyncData` to refetch. When it's not specified, all `useAsyncData` and `useFetch` will be refetched.
|
||||
|
||||
@ -12,7 +12,7 @@ Within your pages, components and plugins you can use `throwError` to throw an e
|
||||
throwError("😱 Oh no, an error has been thrown.")
|
||||
```
|
||||
|
||||
The thrown error is set in state using [`useError()`](/api/composables/use-error) to create a reactive and SSR-friendly shared error state across components.
|
||||
The thrown error is set in the state using [`useError()`](/api/composables/use-error) to create a reactive and SSR-friendly shared error state across components.
|
||||
|
||||
`throwError` calls the `app:error` hook.
|
||||
|
||||
|
||||
@ -1,12 +1,12 @@
|
||||
# `nuxi analyze`
|
||||
|
||||
Analyze the production bundle or your Nuxt applicaiton.
|
||||
Analyze the production bundle or your Nuxt application.
|
||||
|
||||
```{bash}
|
||||
npx nuxi analyze [rootDir]
|
||||
```
|
||||
|
||||
The `analyze` command builds nuxt and analyzes the production bundle (experimental)
|
||||
The `analyze` command builds Nuxt and analyzes the production bundle (experimental).
|
||||
|
||||
Option | Default | Description
|
||||
-------------------------|-----------------|------------------
|
||||
|
||||
@ -4,7 +4,7 @@
|
||||
npx nuxi info [rootDir]
|
||||
```
|
||||
|
||||
The `info` command logs informations about the current or specified Nuxt project.
|
||||
The `info` command logs information about the current or specified Nuxt project.
|
||||
|
||||
Option | Default | Description
|
||||
-------------------------|-----------------|------------------
|
||||
|
||||
@ -10,7 +10,7 @@ Option | Default | Description
|
||||
-------------------------|-----------------|------------------
|
||||
`rootDir` | `.` | The directory of the target application.
|
||||
|
||||
This command sets `process.env.NODE_ENV` to `production`. To override, define `NODE_ENV` in a `.env` file or as command-line argument.
|
||||
This command sets `process.env.NODE_ENV` to `production`. To override, define `NODE_ENV` in a `.env` file or as a command-line argument.
|
||||
|
||||
::alert
|
||||
You can also enable type-checking at build or development time with [the `typescript.typeCheck` option in your `nuxt.config` file](/api/configuration/nuxt.config#typescript).
|
||||
|
||||
@ -4,7 +4,7 @@ template: Example
|
||||
|
||||
# Components
|
||||
|
||||
Components in the `components/` directory are auto imported and can be directly used in your templates.
|
||||
Components in the `components/` directory are auto-imported and can be used directly in your templates.
|
||||
You can configure other directories to support components auto-imports.
|
||||
|
||||
::ReadMore{link="/guide/directory-structure/components"}
|
||||
|
||||
@ -4,7 +4,7 @@ template: Example
|
||||
|
||||
# Composables
|
||||
|
||||
This example shows how to use the `composables/` directory to auto import composables.
|
||||
This example shows how to use the `composables/` directory to auto-import composables.
|
||||
If the component file provides a default export, the name of the composable will be mapped to the name of the file. Named exports can be used as-is.
|
||||
|
||||
::ReadMore{link="/guide/directory-structure/composables"}
|
||||
|
||||
@ -7,7 +7,7 @@ template: Example
|
||||
This example shows how to use `useAsyncData` to fetch data from an API endpoint.
|
||||
|
||||
::alert{type=info icon=💡}
|
||||
Nuxt will automatically read files in the ~/server/api directory to create API endpoints.
|
||||
Nuxt will automatically read files in the `~/server/api` directory to create API endpoints.
|
||||
::
|
||||
|
||||
::ReadMore{link="/api/composables/use-async-data"}
|
||||
|
||||
@ -4,7 +4,7 @@ template: Example
|
||||
|
||||
# `useCookie`
|
||||
|
||||
This example shows how to use the `useCookie` API to persist small amounts of data that both client-side and server-side can use.
|
||||
This example shows how to use the `useCookie` API to persist small amounts of data that both client and server can use.
|
||||
|
||||
::ReadMore{link="/api/composables/use-cookie"}
|
||||
::
|
||||
|
||||
@ -7,7 +7,7 @@ template: Example
|
||||
This example shows how to use `useFetch` to fetch data from an API endpoint.
|
||||
|
||||
::alert{type=info icon=💡}
|
||||
Nuxt will automatically read files in the ~/server/api directory to create API endpoints.
|
||||
Nuxt will automatically read files in the `~/server/api` directory to create API endpoints.
|
||||
::
|
||||
|
||||
::ReadMore{link="/api/composables/use-fetch"}
|
||||
|
||||
@ -4,7 +4,7 @@ template: Example
|
||||
|
||||
# Middleware
|
||||
|
||||
This example shows how to add route middleware with the middleware/ directory or with a plugin, and how to use them globally or per page.
|
||||
This example shows how to add route middleware with the `middleware/` directory or with a plugin, and how to use them globally or per page.
|
||||
|
||||
::ReadMore{link="/guide/directory-structure/middleware"}
|
||||
::
|
||||
|
||||
@ -4,7 +4,7 @@ template: Example
|
||||
|
||||
# Server Routes
|
||||
|
||||
This example shows how to create server routes inside a `server/api` directory.
|
||||
This example shows how to create server routes inside the `server/api` directory.
|
||||
|
||||
::ReadMore{link="/guide/features/server-routes"}
|
||||
::
|
||||
|
||||
@ -4,6 +4,6 @@ template: Example
|
||||
|
||||
# Config extends
|
||||
|
||||
This example shows how to use the `extends` key in nuxt.config.ts to use the base/ directory as a base Nuxt application, and use its components, composables or config and override them if necessary.
|
||||
This example shows how to use the `extends` key in nuxt.config.ts to use the `base/` directory as a base Nuxt application, and use its components, composables or config and override them if necessary.
|
||||
|
||||
::sandbox{repo="nuxt/framework" branch="main" dir="examples/advanced/config-extends" file="nuxt.config.ts"}
|
||||
|
||||
@ -4,9 +4,9 @@ template: Example
|
||||
|
||||
# Reactivity Transform
|
||||
|
||||
This example demonstrates the support of Reactivity transform in Nuxt 3.
|
||||
This example demonstrates the support of Reactivity Transform in Nuxt 3.
|
||||
|
||||
::ReadMore{link="https://vuejs.org/guide/extras/reactivity-transform.html" title="Reactivity transform"}
|
||||
::ReadMore{link="https://vuejs.org/guide/extras/reactivity-transform.html" title="Reactivity Transform"}
|
||||
::
|
||||
|
||||
::sandbox{repo="nuxt/framework" branch="main" dir="examples/experimental/reactivity-transform" file="app.vue"}
|
||||
|
||||
@ -4,10 +4,10 @@ template: Example
|
||||
|
||||
# Locale
|
||||
|
||||
This example shows how to define a locale composable to handle the application's locale, both server and client-side.
|
||||
This example shows how to define a locale composable to handle the application's locale, both server and client side.
|
||||
|
||||
::alert{type=info icon=💡}
|
||||
You can right click to "View Page Source" and see that Nuxt renders the correct date in SSR based on visitor's locale.
|
||||
You can right-click to "View Page Source" and see that Nuxt renders the correct date in SSR based on the visitor's locale.
|
||||
::
|
||||
|
||||
::sandbox{repo="nuxt/framework" branch="main" dir="examples/other/locale" file="app.vue"}
|
||||
|
||||
@ -1,6 +1,6 @@
|
||||
# Reporting Bugs
|
||||
|
||||
Try as we might, we never completely eliminate bugs. One of the most valuable roles in open source is taking the time to report bugs helpfully. Even if you can't fix the underlying code, reporting a bug well can enable someone else with a bit more familiarity with the codebase to spot a pattern or make a quick fix.
|
||||
Try as we might, we will never completely eliminate bugs. One of the most valuable roles in open source is taking the time to report bugs helpfully. Even if you can't fix the underlying code, reporting a bug well can enable someone else with a bit more familiarity with the codebase to spot a pattern or make a quick fix.
|
||||
|
||||
Here are a few key steps.
|
||||
|
||||
|
||||
@ -7,7 +7,7 @@ head.titleTemplate: ''
|
||||
|
||||
## `app.vue`
|
||||
|
||||
Nuxt 3 provides a central entrypoint to your app via `~/app.vue`. If you don't have an `app.vue` file in your source directory, Nuxt will use its own default version.
|
||||
Nuxt 3 provides a central entry point to your app via `~/app.vue`. If you don't have an `app.vue` file in your source directory, Nuxt will use its own default version.
|
||||
|
||||
This file is a great place to put any custom code that needs to be run once when your app starts up, as well as any components that are present on every page of your app. For example, if you only have one layout, you can move this to `app.vue` instead.
|
||||
|
||||
|
||||
@ -17,7 +17,7 @@ export const vueAppPatterns = (nuxt: Nuxt) => [
|
||||
[/nuxt\.config/, 'Importing directly from a `nuxt.config` file is not allowed. Instead, use runtime config or a module.'],
|
||||
[/(^|node_modules\/)@vue\/composition-api/],
|
||||
...nuxt.options.modules.filter(m => typeof m === 'string').map((m: string) =>
|
||||
[new RegExp(`^${escapeRE(m)}$`), 'Importing directly from module entrypoints is not allowed.']),
|
||||
[new RegExp(`^${escapeRE(m)}$`), 'Importing directly from module entry points is not allowed.']),
|
||||
...[/(^|node_modules\/)@nuxt\/kit/, /^nitropack/]
|
||||
.map(i => [i, 'This module cannot be imported in the Vue part of your app.']),
|
||||
[new RegExp(escapeRE(resolve(nuxt.options.srcDir, (nuxt.options.dir as any).server || 'server'))), 'Importing from server middleware is not allowed in the Vue part of your app.']
|
||||
|
||||
@ -570,7 +570,7 @@ export default {
|
||||
/**
|
||||
* You can provide your custom files to watch and regenerate after changes.
|
||||
*
|
||||
* This feature is specially useful for using with modules.
|
||||
* This feature is especially useful for using with modules.
|
||||
*
|
||||
* @example
|
||||
* ```js
|
||||
|
||||
@ -2,7 +2,7 @@ export default {
|
||||
/** @version 3 */
|
||||
experimental: {
|
||||
/**
|
||||
* Set to true to generate an async entrypoint for the Vue bundle (for module federation support).
|
||||
* Set to true to generate an async entry point for the Vue bundle (for module federation support).
|
||||
*/
|
||||
asyncEntry: {
|
||||
$resolve: (val, get) => val ?? (get('dev') && get('experimental.viteNode')) ?? false
|
||||
|
||||
Loading…
Reference in New Issue
Block a user