-
-
-
-
-
+
+
+
+
+
+
```
-::LinkExample{link="/docs/examples/routing/layouts"}
+::LinkExample{link="/docs/examples/features/layouts"}
::
## Overriding a Layout on a Per-page Basis
@@ -141,6 +141,12 @@ If you are using the `~/pages` integration, you can take full control by setting
::code-group
```vue [pages/index.vue]
+
+
{{ $route.params.slug }}
@@ -182,7 +186,7 @@ This file tree will generate these routes: ] ``` -To display the `child.vue` component, you have to insert the `I am the parent view
-
{{ $hello('world') }}
-
-
```
## Typing Plugins
@@ -141,8 +190,6 @@ If you are using WebStorm, you may need to augment `@vue/runtime-core` until [th
If you want to use Vue plugins, like [vue-gtag](https://github.com/MatteoGabriele/vue-gtag) to add Google Analytics tags, you can use a Nuxt plugin to do so.
-> There is an Open RFC to make this even easier! See [nuxt/nuxt#17143](https://github.com/nuxt/nuxt/discussions/17143)
-
First, install the plugin you want.
```bash
@@ -182,7 +229,8 @@ export default defineNuxtPlugin((nuxtApp) => {
})
```
-:ReadMore{link="https://vuejs.org/guide/reusability/custom-directives.html"}
-
-::LinkExample{link="/docs/examples/app/plugins"}
+::alert{type=warning}
+If you register a Vue directive, you _must_ register it on both client and server side unless you are only using it when rendering one side. If the directive only makes sense from a client side, you can always move it to `~/plugins/my-directive.client.ts` and provide a 'stub' directive for the server in `~/plugins/my-directive.server.ts`.
::
+
+:ReadMore{link="https://vuejs.org/guide/reusability/custom-directives.html"}
diff --git a/docs/2.guide/2.directory-structure/1.public.md b/docs/2.guide/2.directory-structure/1.public.md
index 0871b867b9..e351be0a50 100644
--- a/docs/2.guide/2.directory-structure/1.public.md
+++ b/docs/2.guide/2.directory-structure/1.public.md
@@ -7,8 +7,8 @@ head.title: "public/"
# Public Directory
-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`).
+The [`public/` directory](/docs/guide/directory-structure/public) 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.
+This is known as the [`static/` directory](https://nuxtjs.org/docs/directory-structure/static) in Nuxt 2.
::
diff --git a/docs/2.guide/2.directory-structure/1.server.md b/docs/2.guide/2.directory-structure/1.server.md
index 36927a446f..5e0499f08f 100644
--- a/docs/2.guide/2.directory-structure/1.server.md
+++ b/docs/2.guide/2.directory-structure/1.server.md
@@ -7,33 +7,46 @@ description: The server/ directory is used to register API and server handlers t
# Server Directory
-Nuxt automatically scans files inside the `~/server/api`, `~/server/routes`, and `~/server/middleware` directories to register API and server handlers with HMR support.
+Nuxt automatically scans files inside these directories to register API and server handlers with HMR support:
+- `~/server/api`
+- `~/server/routes`
+- `~/server/middleware`
-Each file should export a default function defined with `defineEventHandler()`.
+Each file should export a default function defined with `defineEventHandler()` or `eventHandler()` (alias).
-The handler can directly return JSON data, a `Promise` or use `event.node.res.end()` to send response.
+The handler can directly return JSON data, a `Promise`, or use `event.node.res.end()` to send a response.
-::ReadMore{link="https://nitro.unjs.io/guide/routing" title="Nitro Route Handling Docs"}
-::
-
-## Example
-
-Create a new file in `server/api/hello.ts`:
+**Example:** Create the `/api/hello` route with `server/api/hello.ts` file:
```ts [server/api/hello.ts]
export default defineEventHandler((event) => {
return {
- api: 'works'
+ hello: 'world'
}
})
```
-You can now universally call this API using `await $fetch('/api/hello')`.
+You can now universally call this API in your pages and components:
+
+```vue [pages/index.vue]
+
+
+
+ {{ data }}
+
+```
+
+Note that [h3 utilities](https://github.com/unjs/h3#utilities) are auto-imported.
+
+:ReadMore{link="https://nitro.unjs.io/guide/routing" title="Nitro Route Handling Docs"}
## Server Routes
Files inside the `~/server/api` are automatically prefixed with `/api` in their route.
-For adding server routes without `/api` prefix, you can instead put them into `~/server/routes` directory.
+
+To add server routes without `/api` prefix, put them into `~/server/routes` directory.
**Example:**
@@ -43,6 +56,10 @@ export default defineEventHandler(() => 'Hello World!')
Given the example above, the `/hello` route will be accessible at
-
-
-
+
+
+ Post state: {{ resDataSuccess }}
- Get Data: {{ resData.text }}
-
+
+
```
::ReadMore{link="/docs/guide/directory-structure/server"}
diff --git a/docs/2.guide/2.directory-structure/1.utils.md b/docs/2.guide/2.directory-structure/1.utils.md
index 212550c517..97d257f3cc 100644
--- a/docs/2.guide/2.directory-structure/1.utils.md
+++ b/docs/2.guide/2.directory-structure/1.utils.md
@@ -7,10 +7,10 @@ description: Use the utils/ directory to auto-import your utility functions thro
# Utils Directory
-Nuxt 3 uses the `utils/` directory to automatically import helper functions and other utilities throughout your application using [auto-imports](/docs/guide/concepts/auto-imports)!
+Nuxt 3 uses the [`utils/` directory](/docs/guide/directory-structure/utils) to automatically import helper functions and other utilities throughout your application using [auto-imports](/docs/guide/concepts/auto-imports)!
::alert{type=info}
-The main purpose of the `utils/` directory is to allow a semantic distinction between your Vue composables and other auto-imported utility functions.
+The main purpose of the [`utils/` directory](/docs/guide/directory-structure/utils) is to allow a semantic distinction between your Vue composables and other auto-imported utility functions.
The way `utils/` auto-imports work and are scanned is identical to [the composables/ directory](/docs/guide/directory-structure/composables). You can see examples and more information about how they work in that section of the docs.
::
diff --git a/docs/2.guide/2.directory-structure/2.env.md b/docs/2.guide/2.directory-structure/2.env.md
index 6350415755..1d353907b6 100644
--- a/docs/2.guide/2.directory-structure/2.env.md
+++ b/docs/2.guide/2.directory-structure/2.env.md
@@ -7,6 +7,8 @@ head.title: ".env"
# .env File
+## At Build, Dev, and Generate Time
+
Nuxt CLI has built-in [dotenv](https://github.com/motdotla/dotenv) support in development mode and when running `nuxi build` and `nuxi generate`.
In addition to any process environment variables, if you have a `.env` file in your project root directory, it will be automatically loaded **at build, dev, and generate time**, and any environment variables set there will be accessible within your `nuxt.config` file and modules.
@@ -27,7 +29,17 @@ When updating `.env` in development mode, the Nuxt instance is automatically res
Note that removing a variable from `.env` or removing the `.env` file entirely will not unset values that have already been set.
::
-However, **after your server is built**, you are responsible for setting environment variables when you run the server. Your `.env` file will not be read at this point. How you do this is different for every environment. On a Linux server, you could pass the environment variables as arguments using the terminal `DATABASE_HOST=mydatabaseconnectionstring node .output/server/index.mjs`. Or you could source your env file using `source .env && node .output/server/index.mjs`.
+## Production Preview
+
+**After your server is built**, you are responsible for setting environment variables when you run the server. Your `.env` file will not be read at this point. How you do this is different for every environment.
+
+For local production preview purpose, we recommend using [`nuxi preview`](https://nuxt.com/docs/api/commands/preview) since using this command, the `.env` file will be loaded into `process.env` for convenience. Note that this command requires dependencies to be installed in the package directory.
+
+Or you could pass the environment variables as arguments using the terminal. For example, on Linux or macOS:
+
+```bash
+DATABASE_HOST=mydatabaseconnectionstring node .output/server/index.mjs
+```
Note that for a purely static site, it is not possible to set runtime configuration config after your project is prerendered.
diff --git a/docs/2.guide/2.directory-structure/2.gitignore.md b/docs/2.guide/2.directory-structure/2.gitignore.md
index 8760500a31..d2020a77fb 100644
--- a/docs/2.guide/2.directory-structure/2.gitignore.md
+++ b/docs/2.guide/2.directory-structure/2.gitignore.md
@@ -15,8 +15,18 @@ We recommend having a `.gitignore` file that has **at least** the following entr
# Nuxt dev/build outputs
.output
.nuxt
+
# Node dependencies
node_modules
-# System files
+
+# Logs
+logs
*.log
+
+# Misc
+.DS_Store
+
+# Local env files
+.env.*
+!.env.example
```
diff --git a/docs/2.guide/2.directory-structure/2.nuxtignore.md b/docs/2.guide/2.directory-structure/2.nuxtignore.md
index 67763da971..4fbdb38b47 100644
--- a/docs/2.guide/2.directory-structure/2.nuxtignore.md
+++ b/docs/2.guide/2.directory-structure/2.nuxtignore.md
@@ -9,7 +9,7 @@ description: The .nuxtignore file lets Nuxt ignore files in your project’s roo
The `.nuxtignore` file lets Nuxt ignore `layouts`, `pages`, `components`, `composables` and `middleware` files in your project’s root directory (`rootDir`) during the build phase. The `.nuxtignore` file is subject to the same specification as `.gitignore` and `.eslintignore` files, in which each line is a glob pattern indicating which files should be ignored.
-**Note**: You can also configure [`ignoreOptions`](/docs/guide/directory-structure/nuxt.config#ignoreoptions), [`ignorePrefix`](/docs/guide/directory-structure/nuxt.config#ignoreprefix) and [`ignore`](/docs/guide/directory-structure/nuxt.config#ignore) in your `nuxt.config` file.
+**Note**: You can also configure [`ignoreOptions`](/docs/api/configuration/nuxt-config#ignoreoptions), [`ignorePrefix`](/docs/api/configuration/nuxt-config#ignoreprefix) and [`ignore`](/docs/api/configuration/nuxt-config#ignore) in your `nuxt.config` file.
## Example
diff --git a/docs/2.guide/2.directory-structure/3.app-config.md b/docs/2.guide/2.directory-structure/3.app-config.md
index 30cdd7b3e5..5aa08da7b0 100644
--- a/docs/2.guide/2.directory-structure/3.app-config.md
+++ b/docs/2.guide/2.directory-structure/3.app-config.md
@@ -91,3 +91,32 @@ declare module 'nuxt/schema' {
// It is always important to ensure you import/export something when augmenting a type
export {}
```
+
+### App Config Merging Strategy in Layers
+
+Nuxt uses a custom merging strategy for the `AppConfig` within the layers of your application.
+This strategy is implemented using a [Function Merger](https://github.com/unjs/defu#function-merger), which allows defining a custom merging strategy for every key in `app.config` that has an array as value.
+
+::alert{type=warning}
+The Function Merger should only be used in the base `app.config` of your application.
+::
+
+Here's an example of how you can use:
+
+::code-group
+
+```ts [layer/app.config.ts]
+export default defineAppConfig({
+ // Default array value
+ array: ['hello'],
+})
+```
+
+```ts [app.config.ts]
+export default defineAppConfig({
+ // Overwrite default array value by using a merger function
+ array: () => ['bonjour'],
+})
+```
+
+::
diff --git a/docs/2.guide/2.directory-structure/3.app.md b/docs/2.guide/2.directory-structure/3.app.md
index dc8a5744ec..da3facadba 100644
--- a/docs/2.guide/2.directory-structure/3.app.md
+++ b/docs/2.guide/2.directory-structure/3.app.md
@@ -34,7 +34,7 @@ If you have a [`pages/`](/docs/guide/directory-structure/pages) directory, to di
```
::alert{type=danger}
-Since Nuxt 3 uses [`Post state: {{ resDataSuccess }}
+ Get Data: {{ resData.text }}
+
-
-
-
-
+
+
+ Check developer console!
-
+
+
```
**🛑 Security note:** Be careful not to expose runtime config keys to the client-side by either rendering them or passing them to `useState`.
@@ -150,9 +150,9 @@ It is also possible to type your runtime config manually:
declare module 'nuxt/schema' {
interface RuntimeConfig {
apiSecret: string
- public: {
- apiBase: string
- }
+ }
+ interface PublicRuntimeConfig {
+ apiBase: string
}
}
// It is always important to ensure you import/export something when augmenting a type
diff --git a/docs/2.guide/3.going-further/11.edge-channel.md b/docs/2.guide/3.going-further/11.edge-channel.md
deleted file mode 100644
index b78e2c4dfd..0000000000
--- a/docs/2.guide/3.going-further/11.edge-channel.md
+++ /dev/null
@@ -1,56 +0,0 @@
----
-title: "Edge Channel"
-description: "Edge channel allows to use latest commits from the repository."
----
-
-# Edge Release Channel
-
-Nuxt 3 is landing commits, improvements, and bug fixes every day. You can opt-in to test them earlier before the next release.
-
-After each commit is merged into the `main` branch of [nuxt/nuxt](https://github.com/nuxt/nuxt) and **passing all tests**, we trigger an automated npm release using GitHub Actions publishing Nuxt 3 packages.
-
-You can opt in to use this release channel and avoid waiting for the next release and helping Nuxt by beta testing changes.
-
-The build and publishing method and quality of edge releases are the same as stable ones. The only difference is that you should often check the GitHub repository for updates. There is a slight chance of regressions not being caught during the review process and by the automated tests. Therefore, we internally use this channel to double-check everything before each release.
-
-:::Alert
-Features only available on the edge channel are marked with an alert in the documentation.
-:::
-
-## Opting Into the Edge Channel
-
-Update `nuxt` dependency inside `package.json`:
-
-```diff [package.json]
-{
- "devDependencies": {
--- "nuxt": "^3.0.0"
-++ "nuxt": "npm:nuxt3@latest"
- }
-}
-```
-
-Remove lockfile (`package-lock.json`, `yarn.lock`, or `pnpm-lock.yaml`) and reinstall dependencies.
-
-## Opting Out From the Edge Channel
-
-Update `nuxt` dependency inside `package.json`:
-
-```diff [package.json]
-{
- "devDependencies": {
--- "nuxt": "npm:nuxt3@latest"
-++ "nuxt": "^3.0.0"
- }
-}
-```
-
-Remove lockfile (`package-lock.json`, `yarn.lock`, or `pnpm-lock.yaml`) and reinstall dependencies.
-
-## Using Latest `nuxi` CLI From Edge
-
-:::Alert
-All cli dependencies are bundled because of the building method for reducing `nuxi` package size. You can get dependency updates and CLI improvements using the edge channel.
-:::
-
-You can use `npx nuxi-edge@latest [command]` to try the latest version of the nuxi CLI.
diff --git a/docs/2.guide/3.going-further/11.nightly-release-channel.md b/docs/2.guide/3.going-further/11.nightly-release-channel.md
new file mode 100644
index 0000000000..cee53241d9
--- /dev/null
+++ b/docs/2.guide/3.going-further/11.nightly-release-channel.md
@@ -0,0 +1,56 @@
+---
+title: "Nightly Release Channel"
+description: "The nightly release channel allows using Nuxt built directly from the latest commits to the repository."
+---
+
+# Nightly Release Channel
+
+Nuxt lands commits, improvements, and bug fixes every day. You can opt in to test them earlier before the next release.
+
+After a commit is merged into the `main` branch of [nuxt/nuxt](https://github.com/nuxt/nuxt) and **passes all tests**, we trigger an automated npm release, using GitHub Actions.
+
+You can use these 'nightly' releases to beta test new features and changes.
+
+The build and publishing method and quality of these 'nightly' releases are the same as stable ones. The only difference is that you should often check the GitHub repository for updates. There is a slight chance of regressions not being caught during the review process and by the automated tests. Therefore, we internally use this channel to double-check everything before each release.
+
+:::Alert
+Features that are only available on the nightly release channel are marked with an alert in the documentation.
+:::
+
+## Opting Into the Nightly Release Channel
+
+Update `nuxt` dependency inside `package.json`:
+
+```diff [package.json]
+{
+ "devDependencies": {
+-- "nuxt": "^3.0.0"
+++ "nuxt": "npm:nuxt-nightly@latest"
+ }
+}
+```
+
+Remove lockfile (`package-lock.json`, `yarn.lock`, `pnpm-lock.yaml`, or `bun.lockb`) and reinstall dependencies.
+
+## Opting Out From the Nightly Release Channel
+
+Update `nuxt` dependency inside `package.json`:
+
+```diff [package.json]
+{
+ "devDependencies": {
+-- "nuxt": "npm:nuxt-nightly@latest"
+++ "nuxt": "^3.0.0"
+ }
+}
+```
+
+Remove lockfile (`package-lock.json`, `yarn.lock`, `pnpm-lock.yaml`, or `bun.lockb`) and reinstall dependencies.
+
+## Using Latest `nuxi` CLI From Nightly Release
+
+:::Alert
+All cli dependencies are bundled because of the building method for reducing `nuxi` package size. You can get dependency updates and CLI improvements using the nightly release channel.
+:::
+
+You can use `npx nuxi-edge@latest [command]` to try the latest version of the nuxi CLI.
diff --git a/docs/2.guide/3.going-further/2.hooks.md b/docs/2.guide/3.going-further/2.hooks.md
index 8d0e9f7de8..9b630f7d08 100644
--- a/docs/2.guide/3.going-further/2.hooks.md
+++ b/docs/2.guide/3.going-further/2.hooks.md
@@ -41,9 +41,9 @@ App hooks can be mainly used by [Nuxt Plugins](/docs/guide/directory-structure/p
```js [plugins/test.ts]
export default defineNuxtPlugin((nuxtApp) => {
- nuxtApp.hook('page:start', () => {
- /* your code goes here */
- })
+ nuxtApp.hook('page:start', () => {
+ /* your code goes here */
+ })
})
```
@@ -53,7 +53,7 @@ Learn more about [available lifecycle hooks](/docs/api/advanced/hooks)
## Nitro App Hooks (Runtime)
-These hooks are available for [Nitro plugins](https://nitro.unjs.io/guide/advanced/plugins) to hook into Nitro's runtime behavior.
+These hooks are available for [Nitro plugins](https://nitro.unjs.io/guide/plugins) to hook into Nitro's runtime behavior.
### Usage within a Nitro Plugin
@@ -71,5 +71,28 @@ export default defineNitroPlugin((nitroApp) => {
```
::alert{icon=👉}
-Learn more about available [Nitro lifecycle hooks](/docs/api/advanced/hooks#nitro-hooks-runtime-server-side).
+Learn more about available [Nitro lifecycle hooks](/docs/api/advanced/hooks#nitro-app-hooks-runtime-server-side).
::
+
+## Add additional hooks
+
+You can add additional hooks by augmenting the types provided by Nuxt. This can be useful for modules.
+
+```ts
+import { HookResult } from "@nuxt/schema";
+
+declare module '#app' {
+ interface RuntimeNuxtHooks {
+ 'your-nuxt-runtime-hook': () => HookResult
+ }
+ interface NuxtHooks {
+ 'your-nuxt-hook': () => HookResult
+ }
+}
+
+declare module 'nitropack' {
+ interface NitroRuntimeHooks {
+ 'your-nitro-hook': () => void;
+ }
+}
+```
diff --git a/docs/2.guide/3.going-further/3.modules.md b/docs/2.guide/3.going-further/3.modules.md
index ba73c55f56..2ad2f8b78f 100644
--- a/docs/2.guide/3.going-further/3.modules.md
+++ b/docs/2.guide/3.going-further/3.modules.md
@@ -127,7 +127,19 @@ export default function (inlineOptions, nuxt) {
}
```
-Outside of short inline modules defined in `nuxt.config.ts`, **we do not recommend** using this low-level function definition. Instead, to define a module, **we recommend** using the higher-level `defineNuxtModule` helper provided by [Nuxt Kit](/docs/api/advanced/kit).
+You can get type-hint support for this function using the higher-level `defineNuxtModule` helper provided by [Nuxt Kit](/docs/api/advanced/kit).
+
+```js
+import { defineNuxtModule } from '@nuxt/kit'
+
+export default defineNuxtModule((options, nuxt) => {
+ nuxt.hook('pages:extend', pages => {
+ console.log(`Discovered ${pages.length} pages`)
+ })
+})
+```
+
+However, **we do not recommend** using this low-level function definition. Instead, to define a module, **we recommend** using the object-syntax with `meta` property to identify your module, especially when publishing to npm.
This helper makes writing Nuxt Module more straightforward by implementing many common patterns seen in modules, guaranteeing future compatibility, and improving your module author developer experience and the one of your module users.
@@ -251,7 +263,7 @@ When you need to handle more complex configuration alterations, you should consi
#### Exposing Options to Runtime
-Because modules aren't part of the application runtime, their options aren't too. However, in many cases, you might need access to some of these module options within your runtime code. We recommend exposing the needed config using Nuxt's [`runtimeConfig`](/docs/api/configuration/nuxt-config#runtimeconfig).
+Because modules aren't part of the application runtime, their options aren't either. However, in many cases, you might need access to some of these module options within your runtime code. We recommend exposing the needed config using Nuxt's [`runtimeConfig`](/docs/api/configuration/nuxt-config#runtimeconfig).
@@ -268,7 +280,7 @@ export default defineNuxtModule({
})
```
-Note that we use [`defu`](https://github.com/unjs/defu) to extend the public runtime configuration the user can provides instead of overwritting it.
+Note that we use [`defu`](https://github.com/unjs/defu) to extend the public runtime configuration the user can provides instead of overwriting it.
You can then access your module options in a plugin, component, the application like any other runtime configuration:
@@ -363,6 +375,40 @@ export default defineNuxtModule({
})
```
+#### Injecting Server Routes With `addServerHandler`
+
+```ts
+import { defineNuxtModule, addServerHandler, createResolver } from '@nuxt/kit'
+
+export default defineNuxtModule({
+ setup(options, nuxt) {
+ const resolver = createResolver(import.meta.url)
+
+ addServerHandler({
+ route: '/api/hello',
+ handler: resolver.resolve('./runtime/server/api/hello/index.get.ts')
+ })
+ }
+})
+```
+
+You can also add a dynamic server route:
+
+```ts
+import { defineNuxtModule, addServerHandler, createResolver } from '@nuxt/kit'
+
+export default defineNuxtModule({
+ setup(options, nuxt) {
+ const resolver = createResolver(import.meta.url)
+
+ addServerHandler({
+ route: '/api/hello/:name',
+ handler: resolver.resolve('./runtime/server/api/hello/[name].get.ts')
+ })
+ }
+})
+```
+
#### Injecting Other Assets
If your module should provide other kinds of assets, they can also be injected. Here's a simple example module injecting a stylesheet through Nuxt's `css` array.
@@ -399,6 +445,37 @@ export default defineNuxtModule({
})
```
+#### Using Other Modules in Your Module
+
+If your module depends on other modules, you can add them by using Nuxt Kit's `installModule` utility. For example, if you wanted to use Nuxt Tailwind in your module, you could add it as below:
+
+```ts
+import { defineNuxtModule, createResolver, installModule } from '@nuxt/kit'
+
+export default defineNuxtModuleCheck developer console!
+ Counter: {{ counter || '-' }}
@@ -31,14 +36,9 @@ The example below creates a cookie called `counter`. If the cookie doesn't existUser score: {{ user?.score }}
-
-
-
+
+
+ User score: {{ user?.score }}
+
```
**Example 2:**
```vue
-
-
-
-
-
-
+
+
+ List
-{{ list }}
-
-
-
+
+
```
## Handling Cookies in API Routes
@@ -216,5 +216,5 @@ export default defineEventHandler(event => {
})
```
-::LinkExample{link="/docs/examples/composables/use-cookie"}
+::LinkExample{link="/docs/examples/advanced/use-cookie"}
::
diff --git a/docs/3.api/1.composables/use-fetch.md b/docs/3.api/1.composables/use-fetch.md
index 3fcb1dcab7..b3bdc3cd11 100644
--- a/docs/3.api/1.composables/use-fetch.md
+++ b/docs/3.api/1.composables/use-fetch.md
@@ -1,18 +1,21 @@
# `useFetch`
This composable provides a convenient wrapper around [`useAsyncData`](/docs/api/composables/use-async-data) and [`$fetch`](/docs/api/utils/dollarfetch).
-
It automatically generates a key based on URL and fetch options, provides type hints for request url based on server routes, and infers API response type.
+::alert{type=warning}
+[`useFetch`](/docs/api/composables/use-fetch) is a composable meant to be called directly in a setup function, plugin, or route middleware. It returns reactive composables and handles adding responses to the Nuxt payload so they can be passed from server to client without re-fetching the data on client side when the page hydrates.
+::
+
## Type
```ts [Signature]
-function useFetch(
+function useFetchList
+{{ list }}
+
+
+
{{ pending ? 'Loading' : count }}
-
-
```
::alert{type=warning}
diff --git a/docs/3.api/1.composables/use-lazy-fetch.md b/docs/3.api/1.composables/use-lazy-fetch.md
index f910cf2746..c79f9be1b5 100644
--- a/docs/3.api/1.composables/use-lazy-fetch.md
+++ b/docs/3.api/1.composables/use-lazy-fetch.md
@@ -4,19 +4,30 @@ description: This wrapper around useFetch triggers navigation immediately.
# `useLazyFetch`
-`useLazyFetch` provides a wrapper around `useFetch` that triggers navigation before the handler is resolved by setting the `lazy` option to `true`.
+`useLazyFetch` provides a wrapper around [`useFetch`](/docs/api/composables/use-fetch) that triggers navigation before the handler is resolved by setting the `lazy` option to `true`.
## Description
By default, [useFetch](/docs/api/composables/use-fetch) blocks navigation until its async handler is resolved.
-> `useLazyFetch` has the same signature as `useFetch`.
+> [`useLazyFetch`](/docs/api/composables/use-lazy-fetch) has the same signature as `useFetch`.
:ReadMore{link="/docs/api/composables/use-fetch"}
## Example
```vue
+
+
Loading ...
@@ -27,17 +38,6 @@ By default, [useFetch](/docs/api/composables/use-fetch) blocks navigation until
-
-
```
::alert{type=warning}
diff --git a/docs/3.api/1.composables/use-nuxt-app.md b/docs/3.api/1.composables/use-nuxt-app.md
index d962cca4d0..da1501abdf 100644
--- a/docs/3.api/1.composables/use-nuxt-app.md
+++ b/docs/3.api/1.composables/use-nuxt-app.md
@@ -5,8 +5,8 @@
You can use `useNuxtApp()` within composables, plugins and components.
```vue [app.vue]
-
```
@@ -14,7 +14,7 @@ You can use `useNuxtApp()` within composables, plugins and components.
### `provide (name, value)`
-`nuxtApp` is a runtime context that you can extend using [Nuxt plugins](/docs/guide/directory-structure/plugins). Use the `provide` function to create Nuxt plugins to make values and helper methods available in your Nuxt application across all composables and components.
+`nuxtApp` is a runtime context that you can extend using [Nuxt plugins](/docs/guide/directory-structure/plugins). Use the `provide` function to create Nuxt plugins to make values and helper methods available in your Nuxt application across all composables and components.
`provide` function accepts `name` and `value` parameters.
@@ -52,7 +52,7 @@ export default defineNuxtPlugin((nuxtApp) => {
})
```
-### `callhook(name, ...args)`
+### `callHook(name, ...args)`
`callHook` returns a promise when called with any of the existing hooks.
@@ -70,7 +70,7 @@ await nuxtApp.callHook('my-plugin:init')
- [**component()**](https://vuejs.org/api/application.html#app-component) - Registers a global component if passing both a name string and a component definition, or retrieves an already registered one if only the name is passed.
- [**directive()**](https://vuejs.org/api/application.html#app-directive) - Registers a global custom directive if passing both a name string and a directive definition, or retrieves an already registered one if only the name is passed[(example)](/docs/guide/directory-structure/plugins#vue-directives).
-- [**use()**](https://vuejs.org/api/application.html#app-use) - Installs a **[Vue.js Plugin](https://vuejs.org/guide/reusability/plugins.html)** [(example)](/docs/guide/directory-structure/plugins#vue-plugins).
+- [**use()**](https://vuejs.org/api/application.html#app-use) - Installs a **[Vue.js Plugin](https://vuejs.org/guide/reusability/plugins.html)** [(example)](/docs/guide/directory-structure/plugins#vue-plugins).
:ReadMore{link="https://vuejs.org/api/application.html#application-api"}
@@ -87,21 +87,19 @@ await nuxtApp.callHook('my-plugin:init')
`payload` exposes data and state variables from server side to client side. The following keys will be available on the client after they have been passed from the server side:
- **serverRendered** (boolean) - Indicates if response is server-side-rendered.
-- **data** (object) - When you fetch the data from an API endpoint using either `useFetch` or `useAsyncData`, resulting payload can be accessed from the `payload.data`. This data is cached and helps you prevent fetching the same data in case an identical request is made more than once.
+- **data** (object) - When you fetch the data from an API endpoint using either [`useFetch`](/docs/api/composables/use-fetch) or [`useAsyncData`](/docs/api/composables/use-async-data) , resulting payload can be accessed from the `payload.data`. This data is cached and helps you prevent fetching the same data in case an identical request is made more than once.
```vue [app.vue]
-export default defineComponent({
- async setup() {
- const { data } = await useAsyncData('count', () => $fetch('/api/count'))
- }
-})
+
```
-After fetching the value of `count` using `useAsyncData` in the example above, if you access `payload.data`, you will see `{ count: 1 }` recorded there. The value of `count` is updated whenever the page count increases.
+After fetching the value of `count` using [`useAsyncData`](/docs/api/composables/use-async-data) in the example above, if you access `payload.data`, you will see `{ count: 1 }` recorded there. The value of `count` is updated whenever the page count increases.
When accessing the same `payload.data` from [ssrcontext](#ssrcontext), you can access the same value on the server side as well.
-- **state** (object) - When you use `useState` composable in Nuxt to set shared state, this state data is accessed through `payload.state.[name-of-your-state]`.
+- **state** (object) - When you use [`useState`](/docs/api/composables/use-state) composable in Nuxt to set shared state, this state data is accessed through `payload.state.[name-of-your-state]`.
```js [plugins/my-plugin.ts]
export const useColor = () => useState