@nuxt/docs-nightly 4.1.3-29300098.2f71703a → 4.1.3-29303775.dc69e26c
This diff represents the content of publicly available package versions that have been released to one of the supported registries. The information contained in this diff is provided for informational purposes only and reflects changes between package versions as they appear in their respective public registries.
- package/1.getting-started/01.introduction.md +2 -2
- package/1.getting-started/03.configuration.md +10 -10
- package/1.getting-started/04.views.md +6 -6
- package/1.getting-started/05.assets.md +7 -7
- package/1.getting-started/06.styling.md +5 -5
- package/1.getting-started/07.routing.md +8 -8
- package/1.getting-started/08.seo-meta.md +10 -10
- package/1.getting-started/09.transitions.md +11 -11
- package/1.getting-started/10.data-fetching.md +36 -36
- package/1.getting-started/11.state-management.md +7 -7
- package/1.getting-started/12.error-handling.md +9 -9
- package/1.getting-started/14.layers.md +3 -3
- package/1.getting-started/15.prerendering.md +4 -4
- package/1.getting-started/16.deployment.md +2 -2
- package/1.getting-started/17.testing.md +3 -3
- package/1.getting-started/18.upgrade.md +3 -3
- package/2.guide/1.concepts/1.auto-imports.md +8 -8
- package/2.guide/1.concepts/10.nuxt-lifecycle.md +10 -10
- package/2.guide/1.concepts/2.vuejs-development.md +4 -4
- package/2.guide/1.concepts/3.rendering.md +9 -9
- package/2.guide/1.concepts/4.server-engine.md +5 -5
- package/2.guide/1.concepts/5.modules.md +2 -2
- package/2.guide/1.concepts/7.esm.md +3 -3
- package/2.guide/1.concepts/8.typescript.md +8 -8
- package/2.guide/2.directory-structure/0.nuxt.md +2 -2
- package/2.guide/2.directory-structure/0.output.md +2 -2
- package/2.guide/2.directory-structure/1.app/1.assets.md +2 -2
- package/2.guide/2.directory-structure/1.app/1.components.md +5 -5
- package/2.guide/2.directory-structure/1.app/1.composables.md +3 -3
- package/2.guide/2.directory-structure/1.app/1.layouts.md +6 -6
- package/2.guide/2.directory-structure/1.app/1.middleware.md +7 -7
- package/2.guide/2.directory-structure/1.app/1.pages.md +14 -14
- package/2.guide/2.directory-structure/1.app/1.plugins.md +7 -7
- package/2.guide/2.directory-structure/1.app/1.utils.md +3 -3
- package/2.guide/2.directory-structure/1.app/3.app-config.md +5 -5
- package/2.guide/2.directory-structure/1.app/3.app.md +3 -3
- package/2.guide/2.directory-structure/1.app/3.error.md +1 -1
- package/2.guide/2.directory-structure/1.content.md +2 -2
- package/2.guide/2.directory-structure/1.modules.md +2 -2
- package/2.guide/2.directory-structure/1.node_modules.md +1 -1
- package/2.guide/2.directory-structure/1.server.md +5 -5
- package/2.guide/2.directory-structure/1.shared.md +2 -2
- package/2.guide/2.directory-structure/2.env.md +4 -4
- package/2.guide/2.directory-structure/2.nuxtignore.md +3 -3
- package/2.guide/2.directory-structure/2.nuxtrc.md +2 -2
- package/2.guide/2.directory-structure/3.nuxt-config.md +1 -1
- package/2.guide/2.directory-structure/3.tsconfig.md +2 -2
- package/2.guide/3.going-further/1.experimental-features.md +9 -9
- package/2.guide/3.going-further/1.internals.md +10 -10
- package/2.guide/3.going-further/10.runtime-config.md +4 -4
- package/2.guide/3.going-further/2.hooks.md +3 -3
- package/2.guide/3.going-further/3.modules.md +16 -16
- package/2.guide/3.going-further/4.kit.md +2 -2
- package/2.guide/3.going-further/6.nuxt-app.md +4 -4
- package/2.guide/3.going-further/7.layers.md +11 -11
- package/2.guide/4.recipes/1.custom-routing.md +11 -11
- package/2.guide/4.recipes/2.vite-plugin.md +1 -1
- package/2.guide/4.recipes/3.custom-usefetch.md +3 -3
- package/2.guide/4.recipes/4.sessions-and-authentication.md +1 -1
- package/2.guide/5.best-practices/hydration.md +4 -4
- package/2.guide/5.best-practices/performance.md +4 -4
- package/3.api/1.components/10.nuxt-picture.md +1 -1
- package/3.api/1.components/12.nuxt-route-announcer.md +2 -2
- package/3.api/1.components/2.nuxt-page.md +2 -2
- package/3.api/1.components/3.nuxt-layout.md +2 -2
- package/3.api/1.components/4.nuxt-link.md +3 -3
- package/3.api/1.components/5.nuxt-loading-indicator.md +2 -2
- package/3.api/2.composables/use-async-data.md +6 -6
- package/3.api/2.composables/use-cookie.md +2 -2
- package/3.api/2.composables/use-fetch.md +4 -4
- package/3.api/2.composables/use-head-safe.md +2 -2
- package/3.api/2.composables/use-head.md +2 -2
- package/3.api/2.composables/use-hydration.md +1 -1
- package/3.api/2.composables/use-lazy-async-data.md +2 -2
- package/3.api/2.composables/use-lazy-fetch.md +2 -2
- package/3.api/2.composables/use-loading-indicator.md +2 -2
- package/3.api/2.composables/use-nuxt-app.md +12 -12
- package/3.api/2.composables/use-nuxt-data.md +1 -1
- package/3.api/2.composables/use-preview-mode.md +3 -3
- package/3.api/2.composables/use-request-event.md +1 -1
- package/3.api/2.composables/use-request-fetch.md +2 -2
- package/3.api/2.composables/use-request-header.md +1 -1
- package/3.api/2.composables/use-request-headers.md +1 -1
- package/3.api/2.composables/use-request-url.md +1 -1
- package/3.api/2.composables/use-response-header.md +2 -2
- package/3.api/2.composables/use-route-announcer.md +1 -1
- package/3.api/2.composables/use-route.md +1 -1
- package/3.api/2.composables/use-router.md +4 -4
- package/3.api/2.composables/use-runtime-hook.md +1 -1
- package/3.api/2.composables/use-seo-meta.md +1 -1
- package/3.api/2.composables/use-server-seo-meta.md +3 -3
- package/3.api/2.composables/use-state.md +1 -1
- package/3.api/3.utils/$fetch.md +4 -4
- package/3.api/3.utils/abort-navigation.md +1 -1
- package/3.api/3.utils/add-route-middleware.md +2 -2
- package/3.api/3.utils/call-once.md +1 -1
- package/3.api/3.utils/clear-error.md +1 -1
- package/3.api/3.utils/clear-nuxt-data.md +1 -1
- package/3.api/3.utils/clear-nuxt-state.md +1 -1
- package/3.api/3.utils/define-nuxt-plugin.md +3 -3
- package/3.api/3.utils/define-nuxt-route-middleware.md +3 -3
- package/3.api/3.utils/define-page-meta.md +8 -8
- package/3.api/3.utils/define-route-rules.md +2 -2
- package/3.api/3.utils/navigate-to.md +1 -1
- package/3.api/3.utils/prefetch-components.md +1 -1
- package/3.api/3.utils/prerender-routes.md +1 -1
- package/3.api/3.utils/refresh-nuxt-data.md +2 -2
- package/3.api/3.utils/set-page-layout.md +1 -1
- package/3.api/3.utils/set-response-status.md +1 -1
- package/3.api/3.utils/show-error.md +2 -2
- package/3.api/3.utils/update-app-config.md +1 -1
- package/3.api/4.commands/module.md +2 -2
- package/3.api/4.commands/prepare.md +1 -1
- package/3.api/4.commands/preview.md +2 -2
- package/3.api/4.commands/typecheck.md +1 -1
- package/3.api/5.kit/10.runtime-config.md +1 -1
- package/3.api/5.kit/3.compatibility.md +2 -2
- package/3.api/5.kit/4.autoimports.md +1 -1
- package/3.api/5.kit/5.components.md +2 -2
- package/3.api/5.kit/7.pages.md +3 -3
- package/3.api/5.kit/8.layout.md +1 -1
- package/3.api/6.advanced/1.hooks.md +2 -2
- package/3.api/6.nuxt-config.md +4 -4
- package/5.community/2.getting-help.md +1 -1
- package/5.community/3.reporting-bugs.md +1 -1
- package/5.community/4.contribution.md +10 -10
- package/5.community/5.framework-contribution.md +4 -4
- package/5.community/6.roadmap.md +1 -1
- package/6.bridge/1.overview.md +12 -12
- package/6.bridge/2.typescript.md +1 -1
- package/6.bridge/3.bridge-composition-api.md +5 -5
- package/6.bridge/4.plugins-and-middleware.md +4 -4
- package/6.bridge/5.nuxt3-compatible-api.md +9 -9
- package/6.bridge/6.meta.md +5 -5
- package/6.bridge/7.runtime-config.md +1 -1
- package/6.bridge/8.nitro.md +1 -1
- package/6.bridge/9.vite.md +1 -1
- package/7.migration/1.overview.md +2 -2
- package/7.migration/2.configuration.md +5 -5
- package/7.migration/20.module-authors.md +6 -6
- package/7.migration/3.auto-imports.md +3 -3
- package/7.migration/4.meta.md +3 -3
- package/7.migration/6.pages-and-layouts.md +8 -8
- package/7.migration/7.component-options.md +11 -11
- package/7.migration/8.runtime-config.md +3 -3
- package/package.json +1 -1
|
@@ -40,10 +40,10 @@ The Vue and Nuxt instances are created first. Afterward, Nuxt executes its serve
|
|
|
40
40
|
- Built-in plugins, such as Vue Router and `unhead`.
|
|
41
41
|
- Custom plugins located in the `app/plugins/` directory, including those without a suffix (e.g., `myPlugin.ts`) and those with the `.server` suffix (e.g., `myServerPlugin.server.ts`).
|
|
42
42
|
|
|
43
|
-
Plugins execute in a specific order and may have dependencies on one another. For more details, including execution order and parallelism, refer to the [Plugins documentation](/docs/guide/directory-structure/plugins).
|
|
43
|
+
Plugins execute in a specific order and may have dependencies on one another. For more details, including execution order and parallelism, refer to the [Plugins documentation](/docs/4.x/guide/directory-structure/plugins).
|
|
44
44
|
|
|
45
45
|
::callout{icon="i-lucide-lightbulb"}
|
|
46
|
-
After this step, Nuxt calls the [`app:created`](/docs/api/advanced/hooks#app-hooks-runtime) hook, which can be used to execute additional logic.
|
|
46
|
+
After this step, Nuxt calls the [`app:created`](/docs/4.x/api/advanced/hooks#app-hooks-runtime) hook, which can be used to execute additional logic.
|
|
47
47
|
::
|
|
48
48
|
|
|
49
49
|
:read-more{to="/docs/guide/directory-structure/plugins"}
|
|
@@ -55,7 +55,7 @@ After initializing plugins and before executing middleware, Nuxt calls the `vali
|
|
|
55
55
|
- The `validate` function should return `true` if the parameters are valid.
|
|
56
56
|
- If validation fails, it should return `false` or an object containing a `statusCode` and/or `statusMessage` to terminate the request.
|
|
57
57
|
|
|
58
|
-
For more information, see the [Route Validation documentation](/docs/getting-started/routing#route-validation).
|
|
58
|
+
For more information, see the [Route Validation documentation](/docs/4.x/getting-started/routing#route-validation).
|
|
59
59
|
|
|
60
60
|
:read-more{to="/docs/getting-started/routing#route-validation"}
|
|
61
61
|
|
|
@@ -70,7 +70,7 @@ In Nuxt, there are three types of middleware:
|
|
|
70
70
|
|
|
71
71
|
Nuxt executes all global middleware on the initial page load (both on server and client) and then again before any client-side navigation. Named and anonymous middleware are executed only on the routes specified in the middleware property of the page(route) meta defined in the corresponding page components.
|
|
72
72
|
|
|
73
|
-
For details about each type and examples, see the [Middleware documentation](/docs/guide/directory-structure/app/middleware).
|
|
73
|
+
For details about each type and examples, see the [Middleware documentation](/docs/4.x/guide/directory-structure/app/middleware).
|
|
74
74
|
|
|
75
75
|
Any redirection on the server will result in a `Location:` header being sent to the browser; the browser then makes a fresh request to this new location. All application state will be reset when this happens, unless persisted in a cookie.
|
|
76
76
|
|
|
@@ -99,11 +99,11 @@ Watch a video from Daniel Roe explaining Server Rendering and Global State.
|
|
|
99
99
|
After all required data is fetched and the components are rendered, Nuxt combines the rendered components with settings from `unhead` to generate a complete HTML document. This HTML, along with the associated data, is then sent back to the client to complete the SSR process.
|
|
100
100
|
|
|
101
101
|
::callout{icon="i-lucide-lightbulb"}
|
|
102
|
-
After rendering the Vue application to HTML, Nuxt calls the [`app:rendered`](/docs/api/advanced/hooks#app-hooks-runtime) hook.
|
|
102
|
+
After rendering the Vue application to HTML, Nuxt calls the [`app:rendered`](/docs/4.x/api/advanced/hooks#app-hooks-runtime) hook.
|
|
103
103
|
::
|
|
104
104
|
|
|
105
105
|
::callout{icon="i-lucide-lightbulb"}
|
|
106
|
-
Before finalizing and sending the HTML, Nitro will call the [`render:html`](/docs/api/advanced/hooks#nitro-app-hooks-runtime-server-side) hook. This hook allows you to manipulate the generated HTML, such as injecting additional scripts or modifying meta tags.
|
|
106
|
+
Before finalizing and sending the HTML, Nitro will call the [`render:html`](/docs/4.x/api/advanced/hooks#nitro-app-hooks-runtime-server-side) hook. This hook allows you to manipulate the generated HTML, such as injecting additional scripts or modifying meta tags.
|
|
107
107
|
::
|
|
108
108
|
|
|
109
109
|
## Client (browser)
|
|
@@ -117,7 +117,7 @@ This step is similar to the server-side execution and includes both built-in and
|
|
|
117
117
|
Custom plugins in the `app/plugins/` directory, such as those without a suffix (e.g., `myPlugin.ts`) and with the `.client` suffix (e.g., `myClientPlugin.client.ts`), are executed on the client side.
|
|
118
118
|
|
|
119
119
|
::callout{icon="i-lucide-lightbulb"}
|
|
120
|
-
After this step, Nuxt calls the [`app:created`](/docs/api/advanced/hooks#app-hooks-runtime) hook, which can be used to execute additional logic.
|
|
120
|
+
After this step, Nuxt calls the [`app:created`](/docs/4.x/api/advanced/hooks#app-hooks-runtime) hook, which can be used to execute additional logic.
|
|
121
121
|
::
|
|
122
122
|
|
|
123
123
|
:read-more{to="/docs/guide/directory-structure/plugins"}
|
|
@@ -134,16 +134,16 @@ Nuxt middleware runs on both the server and the client. If you want certain code
|
|
|
134
134
|
|
|
135
135
|
### Step 4: Mount Vue Application and Hydration
|
|
136
136
|
|
|
137
|
-
Calling `app.mount('#__nuxt')` mounts the Vue application to the DOM. If the application uses SSR or SSG mode, Vue performs a hydration step to make the client-side application interactive. During hydration, Vue recreates the application (excluding [Server Components](/docs/guide/directory-structure/app/components#server-components)), matches each component to its corresponding DOM nodes, and attaches DOM event listeners.
|
|
137
|
+
Calling `app.mount('#__nuxt')` mounts the Vue application to the DOM. If the application uses SSR or SSG mode, Vue performs a hydration step to make the client-side application interactive. During hydration, Vue recreates the application (excluding [Server Components](/docs/4.x/guide/directory-structure/app/components#server-components)), matches each component to its corresponding DOM nodes, and attaches DOM event listeners.
|
|
138
138
|
|
|
139
139
|
To ensure proper hydration, it's important to maintain consistency between the data on the server and the client. For API requests, it is recommended to use `useAsyncData`, `useFetch`, or other SSR-friendly composables. These methods ensure that the data fetched on the server side is reused during hydration, avoiding repeated requests. Any new requests should only be triggered after hydration, preventing hydration errors.
|
|
140
140
|
|
|
141
141
|
::callout{icon="i-lucide-lightbulb"}
|
|
142
|
-
Before mounting the Vue application, Nuxt calls the [`app:beforeMount`](/docs/api/advanced/hooks#app-hooks-runtime) hook.
|
|
142
|
+
Before mounting the Vue application, Nuxt calls the [`app:beforeMount`](/docs/4.x/api/advanced/hooks#app-hooks-runtime) hook.
|
|
143
143
|
::
|
|
144
144
|
|
|
145
145
|
::callout{icon="i-lucide-lightbulb"}
|
|
146
|
-
After mounting the Vue application, Nuxt calls the [`app:mounted`](/docs/api/advanced/hooks#app-hooks-runtime) hook.
|
|
146
|
+
After mounting the Vue application, Nuxt calls the [`app:mounted`](/docs/4.x/api/advanced/hooks#app-hooks-runtime) hook.
|
|
147
147
|
::
|
|
148
148
|
|
|
149
149
|
### Step 5: Vue Lifecycle
|
|
@@ -25,13 +25,13 @@ We chose to build Nuxt on top of Vue for these reasons:
|
|
|
25
25
|
|
|
26
26
|
### Auto-imports
|
|
27
27
|
|
|
28
|
-
Every Vue component created in the [`app/components/`](/docs/guide/directory-structure/app/components) directory 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.
|
|
28
|
+
Every Vue component created in the [`app/components/`](/docs/4.x/guide/directory-structure/app/components) directory 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.
|
|
29
29
|
|
|
30
30
|
:read-more{to="/docs/guide/concepts/auto-imports"}
|
|
31
31
|
|
|
32
32
|
### Vue Router
|
|
33
33
|
|
|
34
|
-
Most applications need multiple pages and a way to navigate between them. This is called **routing**. Nuxt uses an [`app/pages/`](/docs/guide/directory-structure/app/pages) directory and naming conventions to directly create routes mapped to your files using the official [Vue Router library](https://router.vuejs.org).
|
|
34
|
+
Most applications need multiple pages and a way to navigate between them. This is called **routing**. Nuxt uses an [`app/pages/`](/docs/4.x/guide/directory-structure/app/pages) directory and naming conventions to directly create routes mapped to your files using the official [Vue Router library](https://router.vuejs.org).
|
|
35
35
|
|
|
36
36
|
:read-more{to="/docs/getting-started/routing"}
|
|
37
37
|
|
|
@@ -91,8 +91,8 @@ const increment = () => count.value++
|
|
|
91
91
|
|
|
92
92
|
The goal of Nuxt is to provide a great developer experience around the Composition API.
|
|
93
93
|
|
|
94
|
-
- Use auto-imported [Reactivity functions](https://vuejs.org/api/reactivity-core.html) from Vue and Nuxt [built-in composables](/docs/api/composables/use-async-data).
|
|
95
|
-
- Write your own auto-imported reusable functions in the [`app/composables/` directory](/docs/guide/directory-structure/app/composables).
|
|
94
|
+
- Use auto-imported [Reactivity functions](https://vuejs.org/api/reactivity-core.html) from Vue and Nuxt [built-in composables](/docs/4.x/api/composables/use-async-data).
|
|
95
|
+
- Write your own auto-imported reusable functions in the [`app/composables/` directory](/docs/4.x/guide/directory-structure/app/composables).
|
|
96
96
|
|
|
97
97
|
### TypeScript Support
|
|
98
98
|
|
|
@@ -3,11 +3,11 @@ title: 'Rendering Modes'
|
|
|
3
3
|
description: 'Learn about the different rendering modes available in Nuxt.'
|
|
4
4
|
---
|
|
5
5
|
|
|
6
|
-
Nuxt supports different rendering modes, [universal rendering](#universal-rendering), [client-side rendering](#client-side-rendering) but also offers [hybrid-rendering](#hybrid-rendering) and the possibility to render your application on [CDN Edge Servers](#edge-side-rendering).
|
|
6
|
+
Nuxt supports different rendering modes, [universal rendering](/docs/guide/concepts/rendering#universal-rendering), [client-side rendering](/docs/guide/concepts/rendering#client-side-rendering) but also offers [hybrid-rendering](/docs/guide/concepts/rendering#hybrid-rendering) and the possibility to render your application on [CDN Edge Servers](/docs/guide/concepts/rendering#edge-side-rendering).
|
|
7
7
|
|
|
8
8
|
Both the browser and server can interpret JavaScript code to turn Vue.js components into HTML elements. This step is called **rendering**. Nuxt supports both **universal** and **client-side** rendering. The two approaches have benefits and downsides that we will cover.
|
|
9
9
|
|
|
10
|
-
By default, Nuxt uses **universal rendering** to provide better user experience, performance and to optimize search engine indexing, but you can switch rendering modes in [one line of configuration](/docs/api/nuxt-config#ssr).
|
|
10
|
+
By default, Nuxt uses **universal rendering** to provide better user experience, performance and to optimize search engine indexing, but you can switch rendering modes in [one line of configuration](/docs/4.x/api/nuxt-config#ssr).
|
|
11
11
|
|
|
12
12
|
## Universal Rendering
|
|
13
13
|
|
|
@@ -42,7 +42,7 @@ const handleClick = () => {
|
|
|
42
42
|
|
|
43
43
|
On the initial request, the `counter` ref is initialized in the server since it is rendered inside the `<p>` tag. The contents of `handleClick` is never executed here. During hydration in the browser, the `counter` ref is re-initialized. The `handleClick` finally binds itself to the button; Therefore it is reasonable to deduce that the body of `handleClick` will always run in a browser environment.
|
|
44
44
|
|
|
45
|
-
[Middlewares](/docs/guide/directory-structure/app/middleware) and [pages](/docs/guide/directory-structure/app/pages) run in the server and on the client during hydration. [Plugins](/docs/guide/directory-structure/plugins) can be rendered on the server or client or both. [Components](/docs/guide/directory-structure/app/components) can be forced to run on the client only as well. [Composables](/docs/guide/directory-structure/app/composables) and [utilities](/docs/guide/directory-structure/app/utils) are rendered based on the context of their usage.
|
|
45
|
+
[Middlewares](/docs/4.x/guide/directory-structure/app/middleware) and [pages](/docs/4.x/guide/directory-structure/app/pages) run in the server and on the client during hydration. [Plugins](/docs/4.x/guide/directory-structure/plugins) can be rendered on the server or client or both. [Components](/docs/4.x/guide/directory-structure/app/components) can be forced to run on the client only as well. [Composables](/docs/4.x/guide/directory-structure/app/composables) and [utilities](/docs/4.x/guide/directory-structure/app/utils) are rendered based on the context of their usage.
|
|
46
46
|
|
|
47
47
|
**Benefits of server-side rendering:**
|
|
48
48
|
- **Performance**: Users can get immediate access to the page's content because browsers can display static content much faster than JavaScript-generated content. At the same time, Nuxt preserves the interactivity of a web application during the hydration process.
|
|
@@ -50,7 +50,7 @@ On the initial request, the `counter` ref is initialized in the server since it
|
|
|
50
50
|
|
|
51
51
|
**Downsides of server-side rendering:**
|
|
52
52
|
- **Development constraints:** Server and browser environments don't provide the same APIs, and it can be tricky to write code that can run on both sides seamlessly. Fortunately, Nuxt provides guidelines and specific variables to help you determine where a piece of code is executed.
|
|
53
|
-
- **Cost:** A server needs to be running in order to render pages on the fly. This adds a monthly cost like any traditional server. However, the server calls are highly reduced thanks to universal rendering with the browser taking over on client-side navigation. A cost reduction is possible by leveraging [edge-side-rendering](#edge-side-rendering).
|
|
53
|
+
- **Cost:** A server needs to be running in order to render pages on the fly. This adds a monthly cost like any traditional server. However, the server calls are highly reduced thanks to universal rendering with the browser taking over on client-side navigation. A cost reduction is possible by leveraging [edge-side-rendering](/docs/guide/concepts/rendering#edge-side-rendering).
|
|
54
54
|
|
|
55
55
|
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.**
|
|
56
56
|
|
|
@@ -96,7 +96,7 @@ If you do use `ssr: false`, you should also place an HTML file in `~/spa-loading
|
|
|
96
96
|
|
|
97
97
|
### Deploying a Static Client-Rendered App
|
|
98
98
|
|
|
99
|
-
If you deploy your app to [static hosting](/docs/getting-started/deployment#static-hosting) with the `nuxt generate` or `nuxt build --prerender` commands, then by default, Nuxt will render every page as a separate static HTML file.
|
|
99
|
+
If you deploy your app to [static hosting](/docs/4.x/getting-started/deployment#static-hosting) with the `nuxt generate` or `nuxt build --prerender` commands, then by default, Nuxt will render every page as a separate static HTML file.
|
|
100
100
|
|
|
101
101
|
::warning
|
|
102
102
|
If you prerender your app with the `nuxt generate` or `nuxt build --prerender` commands, then you will not be able to use any server endpoints as no server will be included in your output folder. If you need server functionality, use `nuxt build` instead.
|
|
@@ -104,7 +104,7 @@ If you prerender your app with the `nuxt generate` or `nuxt build --prerender` c
|
|
|
104
104
|
|
|
105
105
|
If you are using purely client-side rendering, then this might be unnecessary. You might only need a single `index.html` file, plus `200.html` and `404.html` fallbacks, which you can tell your static web host to serve up for all requests.
|
|
106
106
|
|
|
107
|
-
In order to achieve this we can change how the routes are prerendered. Just add this to [your hooks](/docs/api/advanced/hooks#nuxt-hooks-build-time) in your `nuxt.config.ts`:
|
|
107
|
+
In order to achieve this we can change how the routes are prerendered. Just add this to [your hooks](/docs/4.x/api/advanced/hooks#nuxt-hooks-build-time) in your `nuxt.config.ts`:
|
|
108
108
|
|
|
109
109
|
```ts twoslash [nuxt.config.ts]
|
|
110
110
|
export default defineNuxtConfig({
|
|
@@ -126,7 +126,7 @@ The `200.html` and `404.html` might be useful for the hosting provider you are u
|
|
|
126
126
|
|
|
127
127
|
#### Skipping Client Fallback Generation
|
|
128
128
|
|
|
129
|
-
When prerendering a client-rendered app, Nuxt will generate `index.html`, `200.html` and `404.html` files by default. However, if you need to prevent any (or all) of these files from being generated in your build, you can use the `'prerender:generate'` hook from [Nitro](/docs/getting-started/prerendering#prerendergenerate-nitro-hook).
|
|
129
|
+
When prerendering a client-rendered app, Nuxt will generate `index.html`, `200.html` and `404.html` files by default. However, if you need to prevent any (or all) of these files from being generated in your build, you can use the `'prerender:generate'` hook from [Nitro](/docs/4.x/getting-started/prerendering#prerendergenerate-nitro-hook).
|
|
130
130
|
|
|
131
131
|
```ts twoslash [nuxt.config.ts]
|
|
132
132
|
export default defineNuxtConfig({
|
|
@@ -193,7 +193,7 @@ The different properties you can use are the following:
|
|
|
193
193
|
Whenever possible, route rules will be automatically applied to the deployment platform's native rules for optimal performances (Netlify and Vercel are currently supported).
|
|
194
194
|
|
|
195
195
|
::important
|
|
196
|
-
Note that Hybrid Rendering is not available when using [`nuxt generate`](/docs/api/commands/generate).
|
|
196
|
+
Note that Hybrid Rendering is not available when using [`nuxt generate`](/docs/4.x/api/commands/generate).
|
|
197
197
|
::
|
|
198
198
|
|
|
199
199
|
**Examples:**
|
|
@@ -219,7 +219,7 @@ With ESR, the rendering process is pushed to the 'edge' of the network - the CDN
|
|
|
219
219
|
|
|
220
220
|
When a request for a page is made, instead of going all the way to the original server, it's intercepted by the nearest edge server. This server generates the HTML for the page and sends it back to the user. This process minimizes the physical distance the data has to travel, **reducing latency and loading the page faster**.
|
|
221
221
|
|
|
222
|
-
Edge-side rendering is possible thanks to [Nitro](https://nitro.build/), the [server engine](/docs/guide/concepts/server-engine) that powers Nuxt. It offers cross-platform support for Node.js, Deno, Cloudflare Workers, and more.
|
|
222
|
+
Edge-side rendering is possible thanks to [Nitro](https://nitro.build/), the [server engine](/docs/4.x/guide/concepts/server-engine) that powers Nuxt. It offers cross-platform support for Node.js, Deno, Cloudflare Workers, and more.
|
|
223
223
|
|
|
224
224
|
The current platforms where you can leverage ESR are:
|
|
225
225
|
- [Cloudflare Pages](https://pages.cloudflare.com) with zero configuration using the git integration and the `nuxt build` command
|
|
@@ -16,7 +16,7 @@ It is shipped with many features:
|
|
|
16
16
|
|
|
17
17
|
## API Layer
|
|
18
18
|
|
|
19
|
-
Server [API endpoints](/docs/guide/directory-structure/server#
|
|
19
|
+
Server [API endpoints](/docs/4.x/guide/directory-structure/server#server-routes) and [Middleware](/docs/4.x/guide/directory-structure/server#server-middleware) are added by Nitro that internally uses [h3](https://github.com/h3js/h3).
|
|
20
20
|
|
|
21
21
|
Key features include:
|
|
22
22
|
|
|
@@ -32,9 +32,9 @@ Learn more about the API layer in the `server/` directory.
|
|
|
32
32
|
|
|
33
33
|
## Direct API Calls
|
|
34
34
|
|
|
35
|
-
Nitro allows 'direct' calling of routes via the globally-available [`$fetch`](/docs/api/utils/dollarfetch) 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**.
|
|
35
|
+
Nitro allows 'direct' calling of routes via the globally-available [`$fetch`](/docs/4.x/api/utils/dollarfetch) 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**.
|
|
36
36
|
|
|
37
|
-
[`$fetch`](/docs/api/utils/dollarfetch) API is using [ofetch](https://github.com/unjs/ofetch), with key features including:
|
|
37
|
+
[`$fetch`](/docs/4.x/api/utils/dollarfetch) API is using [ofetch](https://github.com/unjs/ofetch), with key features including:
|
|
38
38
|
|
|
39
39
|
- Automatic parsing of JSON responses (with access to raw response if needed)
|
|
40
40
|
- Request body and params are automatically handled, with correct `Content-Type` headers
|
|
@@ -45,7 +45,7 @@ For more information on `$fetch` features, check out [ofetch](https://github.com
|
|
|
45
45
|
|
|
46
46
|
When using API routes (or middleware), Nitro will generate typings for these routes as long as you are returning a value instead of using `res.end()` to send a response.
|
|
47
47
|
|
|
48
|
-
You can access these types when using [`$fetch()`](/docs/api/utils/dollarfetch) or [`useFetch()`](/docs/api/composables/use-fetch).
|
|
48
|
+
You can access these types when using [`$fetch()`](/docs/4.x/api/utils/dollarfetch) or [`useFetch()`](/docs/4.x/api/composables/use-fetch).
|
|
49
49
|
|
|
50
50
|
## Standalone Server
|
|
51
51
|
|
|
@@ -53,7 +53,7 @@ Nitro produces a standalone server dist that is independent of `node_modules`.
|
|
|
53
53
|
|
|
54
54
|
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.
|
|
55
55
|
|
|
56
|
-
Nuxt generates this dist when running `nuxt build` into a [`.output`](/docs/guide/directory-structure/output) directory.
|
|
56
|
+
Nuxt generates this dist when running `nuxt build` into a [`.output`](/docs/4.x/guide/directory-structure/output) directory.
|
|
57
57
|
|
|
58
58
|
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.
|
|
59
59
|
|
|
@@ -7,7 +7,7 @@ description: "Nuxt provides a module system to extend the framework core and sim
|
|
|
7
7
|
|
|
8
8
|
When developing production-grade applications with Nuxt you might find that the framework's core functionality is not enough. Nuxt can be extended with configuration options and plugins, but maintaining these customizations across multiple projects can be tedious, repetitive and time-consuming. On the other hand, supporting every project's needs out of the box would make Nuxt very complex and hard to use.
|
|
9
9
|
|
|
10
|
-
This is one of the reasons why Nuxt provides a module system that makes it possible to extend the core. Nuxt modules are async functions that sequentially run when starting Nuxt in development mode using [`nuxt dev`](/docs/api/commands/dev) or building a project for production with [`nuxt build`](/docs/api/commands/build). They can override templates, configure webpack loaders, add CSS libraries, and perform many other useful tasks.
|
|
10
|
+
This is one of the reasons why Nuxt provides a module system that makes it possible to extend the core. Nuxt modules are async functions that sequentially run when starting Nuxt in development mode using [`nuxt dev`](/docs/4.x/api/commands/dev) or building a project for production with [`nuxt build`](/docs/4.x/api/commands/build). They can override templates, configure webpack loaders, add CSS libraries, and perform many other useful tasks.
|
|
11
11
|
|
|
12
12
|
Best of all, Nuxt modules can be distributed in npm packages. This makes it possible for them to be reused across projects and shared with the community, helping create an ecosystem of high-quality add-ons.
|
|
13
13
|
|
|
@@ -17,7 +17,7 @@ Explore Nuxt Modules
|
|
|
17
17
|
|
|
18
18
|
## Add Nuxt Modules
|
|
19
19
|
|
|
20
|
-
Once you have installed the modules you can add them to your [`nuxt.config.ts`](/docs/guide/directory-structure/nuxt-config) file under the `modules` property. Module developers usually provide additional steps and details for usage.
|
|
20
|
+
Once you have installed the modules you can add them to your [`nuxt.config.ts`](/docs/4.x/guide/directory-structure/nuxt-config) file under the `modules` property. Module developers usually provide additional steps and details for usage.
|
|
21
21
|
|
|
22
22
|
```ts twoslash [nuxt.config.ts]
|
|
23
23
|
export default defineNuxtConfig({
|
|
@@ -32,7 +32,7 @@ export { a }
|
|
|
32
32
|
|
|
33
33
|
Before ECMAScript Modules (ESM) became a standard (it took more than 10 years!), tooling like
|
|
34
34
|
[webpack](https://webpack.js.org/guides/ecma-script-modules) and even languages like TypeScript started supporting so-called **ESM syntax**.
|
|
35
|
-
However, there are some key differences with actual spec; here's [a helpful explainer](https://hacks.mozilla.org/2018/03/es-modules-a-cartoon-deep-dive).
|
|
35
|
+
However, there are some key differences with actual spec; here's [a helpful explainer](https://hacks.mozilla.org/2018/03/es-modules-a-cartoon-deep-dive/).
|
|
36
36
|
|
|
37
37
|
### What is 'Native' ESM?
|
|
38
38
|
|
|
@@ -111,7 +111,7 @@ const { named } = pkg;
|
|
|
111
111
|
|
|
112
112
|
## Troubleshooting ESM Issues
|
|
113
113
|
|
|
114
|
-
If you encounter these errors, the issue is almost certainly with the upstream library. They need to [fix their library](#library-author-guide) to support being imported by Node.
|
|
114
|
+
If you encounter these errors, the issue is almost certainly with the upstream library. They need to [fix their library](/docs/guide/concepts/esm#library-author-guide) to support being imported by Node.
|
|
115
115
|
|
|
116
116
|
### Transpiling Libraries
|
|
117
117
|
|
|
@@ -282,7 +282,7 @@ const someFile = await resolvePath('my-lib', { url: import.meta.url })
|
|
|
282
282
|
|
|
283
283
|
### Best Practices
|
|
284
284
|
|
|
285
|
-
- Prefer named exports rather than default export. This helps reduce CJS conflicts. (see [Default exports](#default-exports) section)
|
|
285
|
+
- Prefer named exports rather than default export. This helps reduce CJS conflicts. (see [Default exports](/docs/guide/concepts/esm#default-exports) section)
|
|
286
286
|
|
|
287
287
|
- Avoid depending on Node.js built-ins and CommonJS or Node.js-only dependencies as much as possible to make your library usable in Browsers and Edge Workers without needing Nitro polyfills.
|
|
288
288
|
|
|
@@ -5,7 +5,7 @@ description: "Nuxt is fully typed and provides helpful shortcuts to ensure you h
|
|
|
5
5
|
|
|
6
6
|
## Type-checking
|
|
7
7
|
|
|
8
|
-
By default, Nuxt doesn't check types when you run [`nuxt dev`](/docs/api/commands/dev) or [`nuxt build`](/docs/api/commands/build), for performance reasons.
|
|
8
|
+
By default, Nuxt doesn't check types when you run [`nuxt dev`](/docs/4.x/api/commands/dev) or [`nuxt build`](/docs/4.x/api/commands/build), for performance reasons.
|
|
9
9
|
|
|
10
10
|
To enable type-checking at build or development time, install `vue-tsc` and `typescript` as development dependency:
|
|
11
11
|
|
|
@@ -29,13 +29,13 @@ To enable type-checking at build or development time, install `vue-tsc` and `typ
|
|
|
29
29
|
|
|
30
30
|
::
|
|
31
31
|
|
|
32
|
-
Then, run [`nuxt typecheck`](/docs/api/commands/typecheck) command to check your types:
|
|
32
|
+
Then, run [`nuxt typecheck`](/docs/4.x/api/commands/typecheck) command to check your types:
|
|
33
33
|
|
|
34
34
|
```bash [Terminal]
|
|
35
35
|
npx nuxt typecheck
|
|
36
36
|
```
|
|
37
37
|
|
|
38
|
-
To enable type-checking at build or development time, you can also use the [`typescript.typeCheck`](/docs/api/nuxt-config#typecheck) option in your `nuxt.config` file:
|
|
38
|
+
To enable type-checking at build or development time, you can also use the [`typescript.typeCheck`](/docs/4.x/api/nuxt-config#typecheck) option in your `nuxt.config` file:
|
|
39
39
|
|
|
40
40
|
```ts twoslash [nuxt.config.ts]
|
|
41
41
|
export default defineNuxtConfig({
|
|
@@ -60,25 +60,25 @@ Some of the references in the file are to files that are only generated within y
|
|
|
60
60
|
This file contains the recommended basic TypeScript configuration for your project, including resolved aliases injected by Nuxt or modules you are using, so you can get full type support and path auto-complete for aliases like `~/file` or `#build/file`.
|
|
61
61
|
|
|
62
62
|
::note
|
|
63
|
-
Consider using the `imports` section of [nuxt.config](/docs/api/nuxt-config#imports) to include directories beyond the default ones. This can be useful for auto-importing types which you're using across your app.
|
|
63
|
+
Consider using the `imports` section of [nuxt.config](/docs/4.x/api/nuxt-config#imports) to include directories beyond the default ones. This can be useful for auto-importing types which you're using across your app.
|
|
64
64
|
::
|
|
65
65
|
|
|
66
|
-
[Read more about how to extend this configuration](/docs/guide/directory-structure/tsconfig).
|
|
66
|
+
[Read more about how to extend this configuration](/docs/4.x/guide/directory-structure/tsconfig).
|
|
67
67
|
|
|
68
68
|
::tip{icon="i-lucide-video" to="https://youtu.be/umLI7SlPygY" target="_blank"}
|
|
69
69
|
Watch a video from Daniel Roe explaining built-in Nuxt aliases.
|
|
70
70
|
::
|
|
71
71
|
|
|
72
72
|
::note
|
|
73
|
-
Nitro also [auto-generates types](/docs/guide/concepts/server-engine#typed-api-routes) for API routes. Plus, Nuxt also generates types for globally available components and [auto-imports from your composables](/docs/guide/directory-structure/app/composables), plus other core functionality.
|
|
73
|
+
Nitro also [auto-generates types](/docs/4.x/guide/concepts/server-engine#typed-api-routes) for API routes. Plus, Nuxt also generates types for globally available components and [auto-imports from your composables](/docs/4.x/guide/directory-structure/app/composables), plus other core functionality.
|
|
74
74
|
::
|
|
75
75
|
|
|
76
76
|
::note
|
|
77
|
-
For backward compatibility, Nuxt still generates `./.nuxt/tsconfig.json`. However, we recommend using [TypeScript project references](/docs/guide/directory-structure/tsconfig) with the new configuration files (`.nuxt/tsconfig.app.json`, `.nuxt/tsconfig.server.json`, etc.) for better type safety and performance.
|
|
77
|
+
For backward compatibility, Nuxt still generates `./.nuxt/tsconfig.json`. However, we recommend using [TypeScript project references](/docs/4.x/guide/directory-structure/tsconfig) with the new configuration files (`.nuxt/tsconfig.app.json`, `.nuxt/tsconfig.server.json`, etc.) for better type safety and performance.
|
|
78
78
|
|
|
79
79
|
If you do extend from `./.nuxt/tsconfig.json`, keep in mind that all options will be overwritten by those defined in your `tsconfig.json`. Overwriting options such as `"compilerOptions.paths"` with your own configuration will lead TypeScript to not factor in the module resolutions, which can cause module resolutions such as `#imports` to not be recognized.
|
|
80
80
|
|
|
81
|
-
In case you need to extend options further, you can use the [`alias` property](/docs/api/nuxt-config#alias) within your `nuxt.config`. Nuxt will pick them up and extend the generated TypeScript configurations accordingly.
|
|
81
|
+
In case you need to extend options further, you can use the [`alias` property](/docs/4.x/api/nuxt-config#alias) within your `nuxt.config`. Nuxt will pick them up and extend the generated TypeScript configurations accordingly.
|
|
82
82
|
::
|
|
83
83
|
|
|
84
84
|
## Project References
|
|
@@ -6,7 +6,7 @@ navigation.icon: i-lucide-folder
|
|
|
6
6
|
---
|
|
7
7
|
|
|
8
8
|
::important
|
|
9
|
-
This directory should be added to your [`.gitignore`](/docs/guide/directory-structure/gitignore) file to avoid pushing the dev build output to your repository.
|
|
9
|
+
This directory should be added to your [`.gitignore`](/docs/4.x/guide/directory-structure/gitignore) file to avoid pushing the dev build output to your repository.
|
|
10
10
|
::
|
|
11
11
|
|
|
12
12
|
This directory is interesting if you want to learn more about the files Nuxt generates based on your directory structure.
|
|
@@ -16,5 +16,5 @@ Nuxt also provides a Virtual File System (VFS) for modules to add templates to t
|
|
|
16
16
|
You can explore the generated files by opening the [Nuxt DevTools](https://devtools.nuxt.com) in development mode and navigating to the **Virtual Files** tab.
|
|
17
17
|
|
|
18
18
|
::warning
|
|
19
|
-
You should not touch any files inside since the whole directory will be re-created when running [`nuxt dev`](/docs/api/commands/dev).
|
|
19
|
+
You should not touch any files inside since the whole directory will be re-created when running [`nuxt dev`](/docs/4.x/api/commands/dev).
|
|
20
20
|
::
|
|
@@ -6,7 +6,7 @@ navigation.icon: i-lucide-folder
|
|
|
6
6
|
---
|
|
7
7
|
|
|
8
8
|
::important
|
|
9
|
-
This directory should be added to your [`.gitignore`](/docs/guide/directory-structure/gitignore) file to avoid pushing the build output to your repository.
|
|
9
|
+
This directory should be added to your [`.gitignore`](/docs/4.x/guide/directory-structure/gitignore) file to avoid pushing the build output to your repository.
|
|
10
10
|
::
|
|
11
11
|
|
|
12
12
|
Use this directory to deploy your Nuxt application to production.
|
|
@@ -14,5 +14,5 @@ Use this directory to deploy your Nuxt application to production.
|
|
|
14
14
|
:read-more{to="/docs/getting-started/deployment"}
|
|
15
15
|
|
|
16
16
|
::warning
|
|
17
|
-
You should not touch any files inside since the whole directory will be re-created when running [`nuxt build`](/docs/api/commands/build).
|
|
17
|
+
You should not touch any files inside since the whole directory will be re-created when running [`nuxt build`](/docs/4.x/api/commands/build).
|
|
18
18
|
::
|
|
@@ -9,8 +9,8 @@ The directory usually contains the following types of files:
|
|
|
9
9
|
|
|
10
10
|
- Stylesheets (CSS, SASS, etc.)
|
|
11
11
|
- Fonts
|
|
12
|
-
- Images that won't be served from the [`public/`](/docs/guide/directory-structure/public) directory.
|
|
12
|
+
- Images that won't be served from the [`public/`](/docs/4.x/guide/directory-structure/public) directory.
|
|
13
13
|
|
|
14
|
-
If you want to serve assets from the server, we recommend taking a look at the [`public/`](/docs/guide/directory-structure/public) directory.
|
|
14
|
+
If you want to serve assets from the server, we recommend taking a look at the [`public/`](/docs/4.x/guide/directory-structure/public) directory.
|
|
15
15
|
|
|
16
16
|
:read-more{to="/docs/getting-started/assets"}
|
|
@@ -344,7 +344,7 @@ Any nested directories need to be added first as they are scanned in order.
|
|
|
344
344
|
|
|
345
345
|
## npm Packages
|
|
346
346
|
|
|
347
|
-
If you want to auto-import components from an npm package, you can use [`addComponent`](/docs/api/kit/components#addcomponent) in a [local module](/docs/guide/directory-structure/modules) to register them.
|
|
347
|
+
If you want to auto-import components from an npm package, you can use [`addComponent`](/docs/4.x/api/kit/components#addcomponent) in a [local module](/docs/4.x/guide/directory-structure/modules) to register them.
|
|
348
348
|
|
|
349
349
|
::code-group
|
|
350
350
|
|
|
@@ -376,7 +376,7 @@ export default defineNuxtModule({
|
|
|
376
376
|
|
|
377
377
|
## Component Extensions
|
|
378
378
|
|
|
379
|
-
By default, any file with an extension specified in the [extensions key of `nuxt.config.ts`](/docs/api/nuxt-config#extensions) is treated as a component.
|
|
379
|
+
By default, any file with an extension specified in the [extensions key of `nuxt.config.ts`](/docs/4.x/api/nuxt-config#extensions) is treated as a component.
|
|
380
380
|
If you need to restrict the file extensions that should be registered as components, you can use the extended form of the components directory declaration and its `extensions` key:
|
|
381
381
|
|
|
382
382
|
```ts twoslash [nuxt.config.ts]
|
|
@@ -424,7 +424,7 @@ You can also achieve a similar result with the `<ClientOnly>` component.
|
|
|
424
424
|
|
|
425
425
|
Server components allow server-rendering individual components within your client-side apps. It's possible to use server components within Nuxt, even if you are generating a static site. That makes it possible to build complex sites that mix dynamic components, server-rendered HTML and even static chunks of markup.
|
|
426
426
|
|
|
427
|
-
Server components can either be used on their own or paired with a [client component](#paired-with-a-client-component).
|
|
427
|
+
Server components can either be used on their own or paired with a [client component](/docs/guide/directory-structure/app/components#paired-with-a-client-component).
|
|
428
428
|
|
|
429
429
|
:video-accordion{title="Watch Learn Vue video about Nuxt Server Components" videoId="u1yyXe86xJM"}
|
|
430
430
|
|
|
@@ -467,7 +467,7 @@ Now you can register server-only components with the `.server` suffix and use th
|
|
|
467
467
|
</template>
|
|
468
468
|
```
|
|
469
469
|
|
|
470
|
-
Server-only components use [`<NuxtIsland>`](/docs/api/components/nuxt-island) under the hood, meaning that `lazy` prop and `#fallback` slot are both passed down to it.
|
|
470
|
+
Server-only components use [`<NuxtIsland>`](/docs/4.x/api/components/nuxt-island) under the hood, meaning that `lazy` prop and `#fallback` slot are both passed down to it.
|
|
471
471
|
|
|
472
472
|
::warning
|
|
473
473
|
Server components (and islands) must have a single root element. (HTML comments are considered elements as well.)
|
|
@@ -554,7 +554,7 @@ There are a number of components that Nuxt provides, including `<ClientOnly>` an
|
|
|
554
554
|
|
|
555
555
|
Making Vue component libraries with automatic tree-shaking and component registration is super easy. ✨
|
|
556
556
|
|
|
557
|
-
You can use the [`addComponentsDir`](/docs/api/kit/components#addcomponentsdir) method provided from the `@nuxt/kit` to register your components directory in your Nuxt module.
|
|
557
|
+
You can use the [`addComponentsDir`](/docs/4.x/api/kit/components#addcomponentsdir) method provided from the `@nuxt/kit` to register your components directory in your Nuxt module.
|
|
558
558
|
|
|
559
559
|
Imagine a directory structure like this:
|
|
560
560
|
|
|
@@ -50,7 +50,7 @@ The `app/composables/` directory in Nuxt does not provide any additional reactiv
|
|
|
50
50
|
|
|
51
51
|
Under the hood, Nuxt auto generates the file `.nuxt/imports.d.ts` to declare the types.
|
|
52
52
|
|
|
53
|
-
Be aware that you have to run [`nuxt prepare`](/docs/api/commands/prepare), [`nuxt dev`](/docs/api/commands/dev) or [`nuxt build`](/docs/api/commands/build) in order to let Nuxt generate the types.
|
|
53
|
+
Be aware that you have to run [`nuxt prepare`](/docs/4.x/api/commands/prepare), [`nuxt dev`](/docs/4.x/api/commands/dev) or [`nuxt build`](/docs/4.x/api/commands/build) in order to let Nuxt generate the types.
|
|
54
54
|
|
|
55
55
|
::note
|
|
56
56
|
If you create a composable without having the dev server running, TypeScript will throw an error, such as `Cannot find name 'useBar'.`
|
|
@@ -71,7 +71,7 @@ export const useFoo = () => {
|
|
|
71
71
|
|
|
72
72
|
### Access plugin injections
|
|
73
73
|
|
|
74
|
-
You can access [plugin injections](/docs/guide/directory-structure/plugins#providing-helpers) from composables:
|
|
74
|
+
You can access [plugin injections](/docs/4.x/guide/directory-structure/plugins#providing-helpers) from composables:
|
|
75
75
|
|
|
76
76
|
```js [app/composables/test.ts]
|
|
77
77
|
export const useHello = () => {
|
|
@@ -82,7 +82,7 @@ export const useHello = () => {
|
|
|
82
82
|
|
|
83
83
|
## How Files Are Scanned
|
|
84
84
|
|
|
85
|
-
Nuxt only scans files at the top level of the [`app/composables/` directory](/docs/guide/directory-structure/app/composables), e.g.:
|
|
85
|
+
Nuxt only scans files at the top level of the [`app/composables/` directory](/docs/4.x/guide/directory-structure/app/composables), e.g.:
|
|
86
86
|
|
|
87
87
|
```bash [Directory Structure]
|
|
88
88
|
-| composables/
|
|
@@ -11,7 +11,7 @@ For best performance, components placed in this directory will be automatically
|
|
|
11
11
|
|
|
12
12
|
## Enable Layouts
|
|
13
13
|
|
|
14
|
-
Layouts are enabled by adding [`<NuxtLayout>`](/docs/api/components/nuxt-layout) to your [`app.vue`](/docs/guide/directory-structure/app):
|
|
14
|
+
Layouts are enabled by adding [`<NuxtLayout>`](/docs/4.x/api/components/nuxt-layout) to your [`app.vue`](/docs/4.x/guide/directory-structure/app):
|
|
15
15
|
|
|
16
16
|
```vue [app/app.vue]
|
|
17
17
|
<template>
|
|
@@ -22,7 +22,7 @@ Layouts are enabled by adding [`<NuxtLayout>`](/docs/api/components/nuxt-layout)
|
|
|
22
22
|
```
|
|
23
23
|
|
|
24
24
|
To use a layout:
|
|
25
|
-
- Set a `layout` property in your page with [definePageMeta](/docs/api/utils/define-page-meta).
|
|
25
|
+
- Set a `layout` property in your page with [definePageMeta](/docs/4.x/api/utils/define-page-meta).
|
|
26
26
|
- Set the `name` prop of `<NuxtLayout>`.
|
|
27
27
|
|
|
28
28
|
::note
|
|
@@ -34,7 +34,7 @@ If no layout is specified, `app/layouts/default.vue` will be used.
|
|
|
34
34
|
::
|
|
35
35
|
|
|
36
36
|
::important
|
|
37
|
-
If you only have a single layout in your application, we recommend using [`app.vue`](/docs/guide/directory-structure/app) instead.
|
|
37
|
+
If you only have a single layout in your application, we recommend using [`app.vue`](/docs/4.x/guide/directory-structure/app) instead.
|
|
38
38
|
::
|
|
39
39
|
|
|
40
40
|
::important
|
|
@@ -78,7 +78,7 @@ definePageMeta({
|
|
|
78
78
|
Learn more about `definePageMeta`.
|
|
79
79
|
::
|
|
80
80
|
|
|
81
|
-
You can directly override the default layout for all pages using the `name` property of [`<NuxtLayout>`](/docs/api/components/nuxt-layout):
|
|
81
|
+
You can directly override the default layout for all pages using the `name` property of [`<NuxtLayout>`](/docs/4.x/api/components/nuxt-layout):
|
|
82
82
|
|
|
83
83
|
```vue [app/app.vue]
|
|
84
84
|
<script setup lang="ts">
|
|
@@ -113,7 +113,7 @@ File | Layout Name
|
|
|
113
113
|
|
|
114
114
|
## Changing the Layout Dynamically
|
|
115
115
|
|
|
116
|
-
You can also use the [`setPageLayout`](/docs/api/utils/set-page-layout) helper to change the layout dynamically:
|
|
116
|
+
You can also use the [`setPageLayout`](/docs/4.x/api/utils/set-page-layout) helper to change the layout dynamically:
|
|
117
117
|
|
|
118
118
|
```vue twoslash
|
|
119
119
|
<script setup lang="ts">
|
|
@@ -176,5 +176,5 @@ definePageMeta({
|
|
|
176
176
|
::
|
|
177
177
|
|
|
178
178
|
::important
|
|
179
|
-
If you use `<NuxtLayout>` within your pages, make sure it is not the root element (or [disable layout/page transitions](/docs/getting-started/transitions#disable-transitions)).
|
|
179
|
+
If you use `<NuxtLayout>` within your pages, make sure it is not the root element (or [disable layout/page transitions](/docs/4.x/getting-started/transitions#disable-transitions)).
|
|
180
180
|
::
|
|
@@ -13,14 +13,14 @@ There are three kinds of route middleware:
|
|
|
13
13
|
2. Named route middleware, placed in the `app/middleware/` and automatically loaded via asynchronous import when used on a page.
|
|
14
14
|
3. Global route middleware, placed in the `app/middleware/` with a `.global` suffix and is run on every route change.
|
|
15
15
|
|
|
16
|
-
The first two kinds of route middleware can be defined in [`definePageMeta`](/docs/api/utils/define-page-meta).
|
|
16
|
+
The first two kinds of route middleware can be defined in [`definePageMeta`](/docs/4.x/api/utils/define-page-meta).
|
|
17
17
|
|
|
18
18
|
::note
|
|
19
19
|
Name of middleware are normalized to kebab-case: `myMiddleware` becomes `my-middleware`.
|
|
20
20
|
::
|
|
21
21
|
|
|
22
22
|
::note
|
|
23
|
-
Route middleware run within the Vue part of your Nuxt app. Despite the similar name, they are completely different from [server middleware](/docs/guide/directory-structure/server#server-middleware), which are run in the Nitro server part of your app.
|
|
23
|
+
Route middleware run within the Vue part of your Nuxt app. Despite the similar name, they are completely different from [server middleware](/docs/4.x/guide/directory-structure/server#server-middleware), which are run in the Nitro server part of your app.
|
|
24
24
|
::
|
|
25
25
|
|
|
26
26
|
:video-accordion{title="Watch a video from Vue School on all 3 kinds of middleware" videoId="761471577" platform="vimeo"}
|
|
@@ -45,8 +45,8 @@ export default defineNuxtRouteMiddleware((to, from) => {
|
|
|
45
45
|
|
|
46
46
|
Nuxt provides two globally available helpers that can be returned directly from the middleware.
|
|
47
47
|
|
|
48
|
-
1. [`navigateTo`](/docs/api/utils/navigate-to) - Redirects to the given route
|
|
49
|
-
2. [`abortNavigation`](/docs/api/utils/abort-navigation) - Aborts the navigation, with an optional error message.
|
|
48
|
+
1. [`navigateTo`](/docs/4.x/api/utils/navigate-to) - Redirects to the given route
|
|
49
|
+
2. [`abortNavigation`](/docs/4.x/api/utils/abort-navigation) - Aborts the navigation, with an optional error message.
|
|
50
50
|
|
|
51
51
|
Unlike [navigation guards](https://router.vuejs.org/guide/advanced/navigation-guards.html#global-before-guards) from `vue-router`, a third `next()` argument is not passed, and **redirect or route cancellation is handled by returning a value from the middleware**.
|
|
52
52
|
|
|
@@ -139,12 +139,12 @@ export default defineNuxtRouteMiddleware(to => {
|
|
|
139
139
|
This is true even if you throw an error in your middleware on the server, and an error page is rendered. The middleware will still run again in the browser.
|
|
140
140
|
|
|
141
141
|
::note
|
|
142
|
-
Rendering an error page is an entirely separate page load, meaning any registered middleware will run again. You can use [`useError`](/docs/getting-started/error-handling#useerror) in middleware to check if an error is being handled.
|
|
142
|
+
Rendering an error page is an entirely separate page load, meaning any registered middleware will run again. You can use [`useError`](/docs/4.x/getting-started/error-handling#useerror) in middleware to check if an error is being handled.
|
|
143
143
|
::
|
|
144
144
|
|
|
145
145
|
## Accessing Route in Middleware
|
|
146
146
|
|
|
147
|
-
Always use the `to` and `from` parameters in your middleware to access the next and previous routes. Avoid using the [`useRoute()`](/docs/api/composables/use-route) composable in this context altogether.
|
|
147
|
+
Always use the `to` and `from` parameters in your middleware to access the next and previous routes. Avoid using the [`useRoute()`](/docs/4.x/api/composables/use-route) composable in this context altogether.
|
|
148
148
|
There is **no concept of a "current route" in middleware**, as middleware can abort a navigation or redirect to a different route. The `useRoute()` composable will always be inaccurate in this context.
|
|
149
149
|
|
|
150
150
|
::warning
|
|
@@ -182,7 +182,7 @@ export function callsRouteInternally() {
|
|
|
182
182
|
|
|
183
183
|
## Adding Middleware Dynamically
|
|
184
184
|
|
|
185
|
-
It is possible to add global or named route middleware manually using the [`addRouteMiddleware()`](/docs/api/utils/add-route-middleware) helper function, such as from within a plugin.
|
|
185
|
+
It is possible to add global or named route middleware manually using the [`addRouteMiddleware()`](/docs/4.x/api/utils/add-route-middleware) helper function, such as from within a plugin.
|
|
186
186
|
|
|
187
187
|
```ts twoslash
|
|
188
188
|
export default defineNuxtPlugin(() => {
|