@nuxt/docs-nightly 4.2.1-29370805.6a102676 → 4.2.1-29370820.95518afa
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/18.upgrade.md +16 -8
- package/2.guide/1.directory-structure/1.node_modules.md +1 -1
- package/2.guide/1.directory-structure/3.tsconfig.md +38 -7
- package/2.guide/2.concepts/8.typescript.md +15 -38
- package/2.guide/3.going-further/3.modules.md +75 -8
- package/3.api/2.composables/use-async-data.md +2 -2
- package/3.api/2.composables/use-cookie.md +1 -1
- package/3.api/2.composables/use-fetch.md +1 -1
- package/3.api/2.composables/use-head-safe.md +37 -20
- package/3.api/2.composables/use-head.md +136 -36
- package/3.api/2.composables/use-hydration.md +24 -18
- package/3.api/2.composables/use-lazy-async-data.md +58 -9
- package/3.api/2.composables/use-lazy-fetch.md +65 -9
- package/3.api/2.composables/use-runtime-hook.md +1 -1
- package/3.api/3.utils/navigate-to.md +1 -1
- package/3.api/5.kit/1.modules.md +1 -1
- package/3.api/5.kit/2.programmatic.md +2 -2
- package/3.api/6.nuxt-config.md +1 -1
- package/5.community/3.reporting-bugs.md +1 -1
- package/package.json +1 -1
|
@@ -1212,22 +1212,30 @@ However, to take advantage of improved type checking, you can opt in to the new
|
|
|
1212
1212
|
Augmenting types from outside the `app/`, `server/`, or `shared/` directories will not work with the new project references setup.
|
|
1213
1213
|
::
|
|
1214
1214
|
|
|
1215
|
-
5. **Configure
|
|
1215
|
+
5. **Configure TypeScript options** if needed:
|
|
1216
1216
|
<!-- @case-police-ignore tsConfig -->
|
|
1217
1217
|
|
|
1218
1218
|
```ts
|
|
1219
1219
|
export default defineNuxtConfig({
|
|
1220
1220
|
typescript: {
|
|
1221
|
-
//
|
|
1221
|
+
// customize tsconfig.app.json
|
|
1222
1222
|
tsConfig: {
|
|
1223
|
-
|
|
1224
|
-
|
|
1225
|
-
|
|
1223
|
+
// ...
|
|
1224
|
+
},
|
|
1225
|
+
// customize tsconfig.shared.json
|
|
1226
|
+
sharedTsConfig: {
|
|
1227
|
+
// ...
|
|
1226
1228
|
},
|
|
1227
|
-
//
|
|
1229
|
+
// customize tsconfig.node.json
|
|
1228
1230
|
nodeTsConfig: {
|
|
1229
|
-
|
|
1230
|
-
|
|
1231
|
+
// ...
|
|
1232
|
+
},
|
|
1233
|
+
},
|
|
1234
|
+
nitro: {
|
|
1235
|
+
typescript: {
|
|
1236
|
+
// customize tsconfig.server.json
|
|
1237
|
+
tsConfig: {
|
|
1238
|
+
// ...
|
|
1231
1239
|
},
|
|
1232
1240
|
},
|
|
1233
1241
|
},
|
|
@@ -5,7 +5,7 @@ head.title: "node_modules/"
|
|
|
5
5
|
navigation.icon: i-vscode-icons-folder-type-node
|
|
6
6
|
---
|
|
7
7
|
|
|
8
|
-
The package manager ([`npm`](https://docs.npmjs.com/cli/commands/npm) or [`yarn`](https://yarnpkg.com) or [`pnpm`](https://pnpm.io/cli/install) or [`bun`](https://bun.com/package-manager)) creates this directory to store the dependencies of your project.
|
|
8
|
+
The package manager ([`npm`](https://docs.npmjs.com/cli/commands/npm/) or [`yarn`](https://yarnpkg.com) or [`pnpm`](https://pnpm.io/cli/install) or [`bun`](https://bun.com/package-manager)) creates this directory to store the dependencies of your project.
|
|
9
9
|
|
|
10
10
|
::important
|
|
11
11
|
This directory should be added to your [`.gitignore`](/docs/4.x/guide/directory-structure/gitignore) file to avoid pushing the dependencies to your repository.
|
|
@@ -1,13 +1,13 @@
|
|
|
1
1
|
---
|
|
2
2
|
title: "tsconfig.json"
|
|
3
|
-
description: "Nuxt
|
|
3
|
+
description: "Learn how Nuxt manages TypeScript configuration across different parts of your project."
|
|
4
4
|
head.title: "tsconfig.json"
|
|
5
5
|
navigation.icon: i-vscode-icons-file-type-tsconfig
|
|
6
6
|
---
|
|
7
7
|
|
|
8
|
-
Nuxt [automatically generates](/docs/4.x/guide/concepts/typescript) multiple TypeScript configuration files (`.nuxt/tsconfig.app.json`, `.nuxt/tsconfig.server.json`, `.nuxt/tsconfig.node.json` and `.nuxt/tsconfig.shared.json`)
|
|
8
|
+
Nuxt [automatically generates](/docs/4.x/guide/concepts/typescript#auto-generated-types) multiple TypeScript configuration files (`.nuxt/tsconfig.app.json`, `.nuxt/tsconfig.server.json`, `.nuxt/tsconfig.node.json` and `.nuxt/tsconfig.shared.json`) that include recommended basic TypeScript configuration for your project, references to [auto-imports](/docs/4.x/guide/concepts/auto-imports), [API route types](/docs/4.x/guide/concepts/server-engine#typed-api-routes), path aliases, and more.
|
|
9
9
|
|
|
10
|
-
|
|
10
|
+
Your Nuxt project should include the following `tsconfig.json` file at the root of the project:
|
|
11
11
|
|
|
12
12
|
```json [tsconfig.json]
|
|
13
13
|
{
|
|
@@ -29,10 +29,41 @@ You can benefit from this by creating a `tsconfig.json` in the root of your proj
|
|
|
29
29
|
}
|
|
30
30
|
```
|
|
31
31
|
|
|
32
|
-
::
|
|
33
|
-
|
|
32
|
+
::warning
|
|
33
|
+
We do not recommend modifying the contents of this file directly, as doing so could overwrite important settings that Nuxt or other modules rely on. Instead, extend it via `nuxt.config.ts`.
|
|
34
34
|
::
|
|
35
35
|
|
|
36
|
-
::
|
|
37
|
-
|
|
36
|
+
::read-more{to="/docs/4.x/guide/concepts/typescript#project-references"}
|
|
37
|
+
Read more about the different type contexts of a Nuxt project here.
|
|
38
38
|
::
|
|
39
|
+
|
|
40
|
+
## Extending TypeScript Configuration
|
|
41
|
+
|
|
42
|
+
You can customize the TypeScript configuration of your Nuxt project for each context (`app`, `shared`, `node`, and `server`) in the `nuxt.config.ts` file.
|
|
43
|
+
<!-- @case-police-ignore tsConfig -->
|
|
44
|
+
```ts twoslash [nuxt.config.ts]
|
|
45
|
+
export default defineNuxtConfig({
|
|
46
|
+
typescript: {
|
|
47
|
+
// customize tsconfig.app.json
|
|
48
|
+
tsConfig: {
|
|
49
|
+
// ...
|
|
50
|
+
},
|
|
51
|
+
// customize tsconfig.shared.json
|
|
52
|
+
sharedTsConfig: {
|
|
53
|
+
// ...
|
|
54
|
+
},
|
|
55
|
+
// customize tsconfig.node.json
|
|
56
|
+
nodeTsConfig: {
|
|
57
|
+
// ...
|
|
58
|
+
},
|
|
59
|
+
},
|
|
60
|
+
nitro: {
|
|
61
|
+
typescript: {
|
|
62
|
+
// customize tsconfig.server.json
|
|
63
|
+
tsConfig: {
|
|
64
|
+
// ...
|
|
65
|
+
},
|
|
66
|
+
},
|
|
67
|
+
},
|
|
68
|
+
})
|
|
69
|
+
```
|
|
@@ -47,56 +47,37 @@ export default defineNuxtConfig({
|
|
|
47
47
|
|
|
48
48
|
## Auto-generated Types
|
|
49
49
|
|
|
50
|
-
|
|
50
|
+
Nuxt projects rely on auto-generated types to work properly. These types are stored in the [`.nuxt`](/docs/4.x/guide/directory-structure/nuxt) directory and are generated when you run the dev server or build your application. You can also generate these files manually by running `nuxt prepare`.
|
|
51
51
|
|
|
52
|
-
|
|
52
|
+
The generated `tsconfig.json` files inside the [`.nuxt`](/docs/4.x/guide/directory-structure/nuxt) directory include **recommended basic TypeScript configuration** for your project, references to [auto-imports](/docs/4.x/guide/concepts/auto-imports), [API route types](/docs/4.x/guide/concepts/server-engine#typed-api-routes), path aliases like `#imports`, `~/file`, or `#build/file`, and more.
|
|
53
53
|
|
|
54
|
-
|
|
55
|
-
|
|
56
|
-
Some of the references in the file are to files that are only generated within your `buildDir` (`.nuxt`) and therefore for full typings, you will need to run `nuxt dev` or `nuxt build`.
|
|
57
|
-
|
|
58
|
-
### `.nuxt/tsconfig.app.json`
|
|
59
|
-
|
|
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
|
-
|
|
62
|
-
::note
|
|
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.
|
|
54
|
+
::warning
|
|
55
|
+
Nuxt relies on this configuration, and [Nuxt Modules](/docs/4.x/guide/going-further/modules) can extend it as well. For this reason, it is not recommended to modify your `tsconfig.json` file directly, as doing so could overwrite important settings. Instead, extend it via `nuxt.config.ts`. [Learn more about extending the configuration here](/docs/4.x/guide/directory-structure/tsconfig).
|
|
64
56
|
::
|
|
65
57
|
|
|
66
|
-
[Read more about how to extend this configuration](/docs/4.x/guide/directory-structure/tsconfig).
|
|
67
|
-
|
|
68
58
|
::tip{icon="i-lucide-video" to="https://youtu.be/umLI7SlPygY" target="_blank"}
|
|
69
59
|
Watch a video from Daniel Roe explaining built-in Nuxt aliases.
|
|
70
60
|
::
|
|
71
61
|
|
|
72
|
-
::note
|
|
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
|
-
::
|
|
75
|
-
|
|
76
|
-
::note
|
|
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
|
-
|
|
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
|
-
|
|
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
|
-
::
|
|
83
|
-
|
|
84
62
|
## Project References
|
|
85
63
|
|
|
86
64
|
Nuxt uses [TypeScript project references](https://www.typescriptlang.org/docs/handbook/project-references.html) to improve type-checking performance and provide better IDE support. This feature allows TypeScript to break up your codebase into smaller, more manageable pieces.
|
|
87
65
|
|
|
88
66
|
### How Nuxt Uses Project References
|
|
89
67
|
|
|
90
|
-
When you run `nuxt dev` or `nuxt
|
|
68
|
+
When you run `nuxt dev`, `nuxt build` or `nuxt prepare`, Nuxt will generate multiple `tsconfig.json` files for different parts of your application.
|
|
91
69
|
|
|
92
|
-
- **`.nuxt/tsconfig.app.json`** - Configuration for your application code
|
|
93
|
-
- **`.nuxt/tsconfig.node.json`** - Configuration for your `nuxt.config` and
|
|
70
|
+
- **`.nuxt/tsconfig.app.json`** - Configuration for your application code within the `app/` directory
|
|
71
|
+
- **`.nuxt/tsconfig.node.json`** - Configuration for your `nuxt.config.ts` and files outside the other contexts
|
|
94
72
|
- **`.nuxt/tsconfig.server.json`** - Configuration for server-side code (when applicable)
|
|
95
73
|
- **`.nuxt/tsconfig.shared.json`** - For code shared between app and server contexts (like types and non-environment specific utilities)
|
|
96
|
-
- **`.nuxt/tsconfig.json`** - Legacy configuration for backward compatibility
|
|
97
74
|
|
|
98
75
|
Each of these files is configured to reference the appropriate dependencies and provide optimal type-checking for their specific context.
|
|
99
76
|
|
|
77
|
+
::note
|
|
78
|
+
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. This legacy file will be removed in a future version of Nuxt.
|
|
79
|
+
::
|
|
80
|
+
|
|
100
81
|
### Benefits of Project References
|
|
101
82
|
|
|
102
83
|
- **Faster builds**: TypeScript can skip rebuilding unchanged projects
|
|
@@ -104,13 +85,9 @@ Each of these files is configured to reference the appropriate dependencies and
|
|
|
104
85
|
- **Isolated compilation**: Errors in one part of your application don't prevent compilation of other parts
|
|
105
86
|
- **Clearer dependency management**: Each project explicitly declares its dependencies
|
|
106
87
|
|
|
107
|
-
::note
|
|
108
|
-
The project reference setup is handled automatically by Nuxt. You typically don't need to modify these configurations manually, but understanding how they work can help you troubleshoot type-checking issues.
|
|
109
|
-
::
|
|
110
|
-
|
|
111
88
|
### Augmenting Types with Project References
|
|
112
89
|
|
|
113
|
-
Since the project is divided into **multiple type contexts**, it's important to **augment types within the correct context** to ensure they
|
|
90
|
+
Since the project is divided into **multiple type contexts**, it's important to **augment types within the correct context** to ensure they're properly recognized. TypeScript will not recognize augmentations placed outside these directories unless they are explicitly included in the appropriate context.
|
|
114
91
|
|
|
115
92
|
For example, if you want to augment types for the `app` context, the augmentation file should be placed in the `app/` directory.
|
|
116
93
|
|
|
@@ -118,15 +95,15 @@ Similarly:
|
|
|
118
95
|
- For the `server` context, place the augmentation file in the `server/` directory.
|
|
119
96
|
- For types that are **shared between the app and server**, place the file in the `shared/` directory.
|
|
120
97
|
|
|
121
|
-
::
|
|
122
|
-
|
|
98
|
+
::read-more{to="/docs/4.x/guide/going-further/modules#extending-tsconfigjson"}
|
|
99
|
+
Read more about augmenting specific type contexts from **files outside those contexts** in the Module Author Guide.
|
|
123
100
|
::
|
|
124
101
|
|
|
125
102
|
## Strict Checks
|
|
126
103
|
|
|
127
104
|
TypeScript comes with certain checks to give you more safety and analysis of your program.
|
|
128
105
|
|
|
129
|
-
[Strict checks](https://www.typescriptlang.org/docs/handbook/migrating-from-javascript.html#getting-stricter-checks) are enabled by default in Nuxt to give you greater type safety.
|
|
106
|
+
[Strict checks](https://www.typescriptlang.org/docs/handbook/migrating-from-javascript.html#getting-stricter-checks) are enabled by default in Nuxt when the [`typescript.typeCheck`](/docs/4.x/guide/concepts/typescript#type-checking) option is enabled to give you greater type safety.
|
|
130
107
|
|
|
131
108
|
If you are currently converting your codebase to TypeScript, you may want to temporarily disable strict checks by setting `strict` to `false` in your `nuxt.config`:
|
|
132
109
|
|
|
@@ -653,6 +653,19 @@ export default defineNuxtModule({
|
|
|
653
653
|
})
|
|
654
654
|
```
|
|
655
655
|
|
|
656
|
+
#### Updating Templates
|
|
657
|
+
|
|
658
|
+
If you need to update your templates/virtual files, you can leverage the `updateTemplates` utility like this:
|
|
659
|
+
|
|
660
|
+
```ts
|
|
661
|
+
nuxt.hook('builder:watch', (event, path) => {
|
|
662
|
+
if (path.includes('my-module-feature.config')) {
|
|
663
|
+
// This will reload the template that you registered
|
|
664
|
+
updateTemplates({ filter: t => t.filename === 'my-module-feature.mjs' })
|
|
665
|
+
}
|
|
666
|
+
})
|
|
667
|
+
```
|
|
668
|
+
|
|
656
669
|
#### Adding Type Declarations
|
|
657
670
|
|
|
658
671
|
You might also want to add a type declaration to the user's project (for example, to augment a Nuxt interface
|
|
@@ -691,19 +704,73 @@ nuxt.hook('prepare:types', ({ references }) => {
|
|
|
691
704
|
})
|
|
692
705
|
```
|
|
693
706
|
|
|
694
|
-
|
|
707
|
+
#### Extending `tsconfig.json`
|
|
708
|
+
|
|
709
|
+
There are multiple ways to extend the TypeScript configuration of the user's project from your module.
|
|
695
710
|
|
|
696
|
-
|
|
711
|
+
The simplest way is to modify the Nuxt configuration directly like this:
|
|
697
712
|
|
|
713
|
+
<!-- @case-police-ignore tsConfig -->
|
|
698
714
|
```ts
|
|
699
|
-
|
|
700
|
-
|
|
701
|
-
|
|
702
|
-
|
|
703
|
-
|
|
715
|
+
// extend tsconfig.app.json
|
|
716
|
+
nuxt.options.typescript.tsConfig.include ??= []
|
|
717
|
+
nuxt.options.typescript.tsConfig.include.push(resolve('./augments.d.ts'))
|
|
718
|
+
|
|
719
|
+
// extend tsconfig.shared.json
|
|
720
|
+
nuxt.options.typescript.sharedTsConfig.include ??= []
|
|
721
|
+
nuxt.options.typescript.sharedTsConfig.include.push(resolve('./augments.d.ts'))
|
|
722
|
+
|
|
723
|
+
// extend tsconfig.node.json
|
|
724
|
+
nuxt.options.typescript.nodeTsConfig.include ??= []
|
|
725
|
+
nuxt.options.typescript.nodeTsConfig.include.push(resolve('./augments.d.ts'))
|
|
726
|
+
|
|
727
|
+
// extend tsconfig.server.json
|
|
728
|
+
nuxt.options.nitro.typescript ??= {}
|
|
729
|
+
nuxt.options.nitro.typescript.tsConfig ??= {}
|
|
730
|
+
nuxt.options.nitro.typescript.tsConfig.include ??= []
|
|
731
|
+
nuxt.options.nitro.typescript.tsConfig.include.push(resolve('./augments.d.ts'))
|
|
732
|
+
```
|
|
733
|
+
|
|
734
|
+
Alternatively, you can use the `prepare:types` and `nitro:prepare:types` hooks to extend the TypeScript references for specific type contexts, or modify the TypeScript configuration similar to the example above.
|
|
735
|
+
|
|
736
|
+
```ts
|
|
737
|
+
nuxt.hook('prepare:types', ({ references, sharedReferences, nodeReferences }) => {
|
|
738
|
+
// extend app context
|
|
739
|
+
references.push({ path: resolve('./augments.d.ts') })
|
|
740
|
+
// extend shared context
|
|
741
|
+
sharedReferences.push({ path: resolve('./augments.d.ts') })
|
|
742
|
+
// extend node context
|
|
743
|
+
nodeReferences.push({ path: resolve('./augments.d.ts') })
|
|
744
|
+
})
|
|
745
|
+
|
|
746
|
+
nuxt.hook('nitro:prepare:types', ({ references }) => {
|
|
747
|
+
// extend server context
|
|
748
|
+
references.push({ path: resolve('./augments.d.ts') })
|
|
704
749
|
})
|
|
705
750
|
```
|
|
706
751
|
|
|
752
|
+
::note
|
|
753
|
+
TypeScript references add files to the type context [without being affected by the `exclude` option in `tsconfig.json`](https://www.typescriptlang.org/tsconfig/#exclude).
|
|
754
|
+
::
|
|
755
|
+
|
|
756
|
+
#### Augmenting Types From Modules
|
|
757
|
+
|
|
758
|
+
Nuxt automatically includes your module's directories in the appropriate type contexts. To augment types from your module, all you need to do is place the type declaration file in the appropriate directory based on the augmented type context. Alternatively, you can [extend the TypeScript configuration](/docs/4.x/guide/going-further/modules#extending-tsconfigjson) to augment from an arbitrary location.
|
|
759
|
+
|
|
760
|
+
- `my-module/runtime/` - app type context (except for the `runtime/server` directory)
|
|
761
|
+
- `my-module/runtime/server/` - server type context
|
|
762
|
+
- `my-module/` - node type context (except for the `runtime/` and `runtime/server` directories)
|
|
763
|
+
|
|
764
|
+
```bash [Directory Structure]
|
|
765
|
+
-| my-module/ # node type context
|
|
766
|
+
---| runtime/ # app type context
|
|
767
|
+
------| augments.app.d.ts
|
|
768
|
+
------| server/ # server type context
|
|
769
|
+
---------| augments.server.d.ts
|
|
770
|
+
---| module.ts
|
|
771
|
+
---| augments.node.d.ts
|
|
772
|
+
```
|
|
773
|
+
|
|
707
774
|
### Testing
|
|
708
775
|
|
|
709
776
|
Testing helps ensuring your module works as expected given various setup. Find in this section how to perform various kinds of tests against your module.
|
|
@@ -774,7 +841,7 @@ An example of such a workflow is available on [the module starter](https://githu
|
|
|
774
841
|
|
|
775
842
|
Having a playground Nuxt application to test your module when developing it is really useful. [The module starter integrates one for that purpose](/docs/4.x/guide/going-further/modules#how-to-develop).
|
|
776
843
|
|
|
777
|
-
You can test your module with other Nuxt applications (applications that are not part of your module repository) locally. To do so, you can use [`npm pack`](https://docs.npmjs.com/cli/commands/npm-pack) command, or your package manager equivalent, to create a tarball from your module. Then in your test project, you can add your module to `package.json` packages as: `"my-module": "file:/path/to/tarball.tgz"`.
|
|
844
|
+
You can test your module with other Nuxt applications (applications that are not part of your module repository) locally. To do so, you can use [`npm pack`](https://docs.npmjs.com/cli/commands/npm-pack/) command, or your package manager equivalent, to create a tarball from your module. Then in your test project, you can add your module to `package.json` packages as: `"my-module": "file:/path/to/tarball.tgz"`.
|
|
778
845
|
|
|
779
846
|
After that, you should be able to reference `my-module` like in any regular project.
|
|
780
847
|
|
|
@@ -234,12 +234,12 @@ export type AsyncDataHandler<ResT> = (nuxtApp: NuxtApp, options: { signal: Abort
|
|
|
234
234
|
|
|
235
235
|
export function useAsyncData<DataT, DataE> (
|
|
236
236
|
handler: AsyncDataHandler<DataT>,
|
|
237
|
-
options?: AsyncDataOptions<DataT
|
|
237
|
+
options?: AsyncDataOptions<DataT>,
|
|
238
238
|
): AsyncData<DataT, DataE>
|
|
239
239
|
export function useAsyncData<DataT, DataE> (
|
|
240
240
|
key: MaybeRefOrGetter<string>,
|
|
241
241
|
handler: AsyncDataHandler<DataT>,
|
|
242
|
-
options?: AsyncDataOptions<DataT
|
|
242
|
+
options?: AsyncDataOptions<DataT>,
|
|
243
243
|
): Promise<AsyncData<DataT, DataE>>
|
|
244
244
|
|
|
245
245
|
type AsyncDataOptions<DataT> = {
|
|
@@ -128,7 +128,7 @@ searchQuery.value = 'new search'
|
|
|
128
128
|
```ts [Signature]
|
|
129
129
|
export function useFetch<DataT, ErrorT> (
|
|
130
130
|
url: string | Request | Ref<string | Request> | (() => string | Request),
|
|
131
|
-
options?: UseFetchOptions<DataT
|
|
131
|
+
options?: UseFetchOptions<DataT>,
|
|
132
132
|
): Promise<AsyncData<DataT, ErrorT>>
|
|
133
133
|
|
|
134
134
|
type UseFetchOptions<DataT> = {
|
|
@@ -8,28 +8,12 @@ links:
|
|
|
8
8
|
size: xs
|
|
9
9
|
---
|
|
10
10
|
|
|
11
|
-
The `useHeadSafe` composable is a wrapper around the [`useHead`](/docs/4.x/api/composables/use-head) composable that restricts the input to only allow safe values.
|
|
12
|
-
|
|
13
11
|
## Usage
|
|
14
12
|
|
|
15
|
-
|
|
16
|
-
|
|
17
|
-
```ts
|
|
18
|
-
useHeadSafe({
|
|
19
|
-
script: [
|
|
20
|
-
{ id: 'xss-script', innerHTML: 'alert("xss")' },
|
|
21
|
-
],
|
|
22
|
-
meta: [
|
|
23
|
-
{ 'http-equiv': 'refresh', 'content': '0;javascript:alert(1)' },
|
|
24
|
-
],
|
|
25
|
-
})
|
|
26
|
-
// Will safely generate
|
|
27
|
-
// <script id="xss-script"></script>
|
|
28
|
-
// <meta content="0;javascript:alert(1)">
|
|
29
|
-
```
|
|
13
|
+
The `useHeadSafe` composable is a wrapper around the [`useHead`](/docs/4.x/api/composables/use-head) composable that restricts the input to only allow safe values. This is the recommended way to manage head data when working with user input, as it prevents XSS attacks by sanitizing potentially dangerous attributes.
|
|
30
14
|
|
|
31
|
-
::
|
|
32
|
-
|
|
15
|
+
::warning
|
|
16
|
+
When using `useHeadSafe`, potentially dangerous attributes like `innerHTML` in scripts or `http-equiv` in meta tags are automatically stripped out to prevent XSS attacks. Use this composable whenever you're working with user-generated content.
|
|
33
17
|
::
|
|
34
18
|
|
|
35
19
|
## Type
|
|
@@ -38,7 +22,9 @@ Read more on the `Unhead` documentation.
|
|
|
38
22
|
export function useHeadSafe (input: MaybeComputedRef<HeadSafe>): void
|
|
39
23
|
```
|
|
40
24
|
|
|
41
|
-
|
|
25
|
+
### Allowed Attributes
|
|
26
|
+
|
|
27
|
+
The following attributes are whitelisted for each head element type:
|
|
42
28
|
|
|
43
29
|
```ts
|
|
44
30
|
const WhitelistAttributes = {
|
|
@@ -53,3 +39,34 @@ const WhitelistAttributes = {
|
|
|
53
39
|
```
|
|
54
40
|
|
|
55
41
|
See [@unhead/vue](https://github.com/unjs/unhead/blob/main/packages/vue/src/types/safeSchema.ts) for more detailed types.
|
|
42
|
+
|
|
43
|
+
## Parameters
|
|
44
|
+
|
|
45
|
+
`input`: A `MaybeComputedRef<HeadSafe>` object containing head data. You can pass all the same values as [`useHead`](/docs/4.x/api/composables/use-head), but only safe attributes will be rendered.
|
|
46
|
+
|
|
47
|
+
## Return Values
|
|
48
|
+
|
|
49
|
+
This composable does not return any value.
|
|
50
|
+
|
|
51
|
+
## Example
|
|
52
|
+
|
|
53
|
+
```vue [app/pages/user-profile.vue]
|
|
54
|
+
<script setup lang="ts">
|
|
55
|
+
// User-generated content that might contain malicious code
|
|
56
|
+
const userBio = ref('<script>alert("xss")<' + '/script>')
|
|
57
|
+
|
|
58
|
+
useHeadSafe({
|
|
59
|
+
title: `User Profile`,
|
|
60
|
+
meta: [
|
|
61
|
+
{
|
|
62
|
+
name: 'description',
|
|
63
|
+
content: userBio.value, // Safely sanitized
|
|
64
|
+
},
|
|
65
|
+
],
|
|
66
|
+
})
|
|
67
|
+
</script>
|
|
68
|
+
```
|
|
69
|
+
|
|
70
|
+
::read-more{to="https://unhead.unjs.io/docs/typescript/head/api/composables/use-head-safe" target="_blank"}
|
|
71
|
+
Read more on the `Unhead` documentation.
|
|
72
|
+
::
|
|
@@ -8,19 +8,38 @@ links:
|
|
|
8
8
|
size: xs
|
|
9
9
|
---
|
|
10
10
|
|
|
11
|
-
|
|
11
|
+
## Usage
|
|
12
12
|
|
|
13
|
-
|
|
13
|
+
The `useHead` composable allows you to manage your head tags in a programmatic and reactive way, powered by [Unhead](https://unhead.unjs.io). It lets you customize the meta tags, links, scripts, and other elements in the `<head>` section of your HTML document.
|
|
14
|
+
|
|
15
|
+
```vue [app/app.vue]
|
|
16
|
+
<script setup lang="ts">
|
|
17
|
+
useHead({
|
|
18
|
+
title: 'My App',
|
|
19
|
+
meta: [
|
|
20
|
+
{ name: 'description', content: 'My amazing site.' },
|
|
21
|
+
],
|
|
22
|
+
bodyAttrs: {
|
|
23
|
+
class: 'test',
|
|
24
|
+
},
|
|
25
|
+
script: [{ innerHTML: 'console.log(\'Hello world\')' }],
|
|
26
|
+
})
|
|
27
|
+
</script>
|
|
28
|
+
```
|
|
29
|
+
|
|
30
|
+
::warning
|
|
31
|
+
If the data comes from a user or other untrusted source, we recommend you check out [`useHeadSafe`](/docs/4.x/api/composables/use-head-safe).
|
|
32
|
+
::
|
|
33
|
+
|
|
34
|
+
::note
|
|
35
|
+
The properties of `useHead` can be dynamic, accepting `ref`, `computed` and `reactive` properties. The `meta` parameter can also accept a function returning an object to make the entire object reactive.
|
|
36
|
+
::
|
|
14
37
|
|
|
15
38
|
## Type
|
|
16
39
|
|
|
17
40
|
```ts [Signature]
|
|
18
41
|
export function useHead (meta: MaybeComputedRef<MetaObject>): void
|
|
19
|
-
```
|
|
20
42
|
|
|
21
|
-
Below are the non-reactive types for [`useHead`](/docs/4.x/api/composables/use-head) .
|
|
22
|
-
|
|
23
|
-
```ts
|
|
24
43
|
interface MetaObject {
|
|
25
44
|
title?: string
|
|
26
45
|
titleTemplate?: string | ((title?: string) => string)
|
|
@@ -35,35 +54,116 @@ interface MetaObject {
|
|
|
35
54
|
}
|
|
36
55
|
```
|
|
37
56
|
|
|
38
|
-
See [@unhead/
|
|
57
|
+
See [@unhead/schema](https://github.com/unjs/unhead/blob/main/packages/vue/src/types/schema.ts) for more detailed types.
|
|
39
58
|
|
|
40
|
-
|
|
41
|
-
|
|
42
|
-
|
|
59
|
+
## Parameters
|
|
60
|
+
|
|
61
|
+
`meta`: An object accepting head metadata properties to customize the page's `<head>` section. All properties support reactive values (`ref`, `computed`, `reactive`) or can be a function returning the metadata object.
|
|
62
|
+
|
|
63
|
+
| Property | Type | Description |
|
|
64
|
+
| --- | --- | --- |
|
|
65
|
+
| `title` | `string` | Sets the page title. |
|
|
66
|
+
| `titleTemplate` | `string \| ((title?: string) => string)` | Configures a dynamic template to customize the page title. Can be a string with `%s` placeholder or a function. |
|
|
67
|
+
| `base` | `Base` | Sets the `<base>` tag for the document. |
|
|
68
|
+
| `link` | `Link[]` | Array of link objects. Each element is mapped to a `<link>` tag, where object properties correspond to HTML attributes. |
|
|
69
|
+
| `meta` | `Meta[]` | Array of meta objects. Each element is mapped to a `<meta>` tag, where object properties correspond to HTML attributes. |
|
|
70
|
+
| `style` | `Style[]` | Array of style objects. Each element is mapped to a `<style>` tag, where object properties correspond to HTML attributes. |
|
|
71
|
+
| `script` | `Script[]` | Array of script objects. Each element is mapped to a `<script>` tag, where object properties correspond to HTML attributes. |
|
|
72
|
+
| `noscript` | `Noscript[]` | Array of noscript objects. Each element is mapped to a `<noscript>` tag, where object properties correspond to HTML attributes. |
|
|
73
|
+
| `htmlAttrs` | `HtmlAttributes` | Sets attributes of the `<html>` tag. Each object property is mapped to the corresponding attribute. |
|
|
74
|
+
| `bodyAttrs` | `BodyAttributes` | Sets attributes of the `<body>` tag. Each object property is mapped to the corresponding attribute. |
|
|
75
|
+
|
|
76
|
+
## Return Values
|
|
77
|
+
|
|
78
|
+
This composable does not return any value. It registers the head metadata with Unhead, which manages the actual DOM updates.
|
|
79
|
+
|
|
80
|
+
## Examples
|
|
81
|
+
|
|
82
|
+
### Basic Meta Tags
|
|
43
83
|
|
|
44
|
-
|
|
45
|
-
|
|
46
|
-
|
|
47
|
-
|
|
48
|
-
|
|
49
|
-
|
|
50
|
-
|
|
51
|
-
|
|
52
|
-
|
|
53
|
-
|
|
54
|
-
|
|
55
|
-
|
|
56
|
-
|
|
57
|
-
|
|
58
|
-
|
|
59
|
-
|
|
60
|
-
|
|
61
|
-
|
|
62
|
-
|
|
63
|
-
|
|
64
|
-
|
|
65
|
-
|
|
66
|
-
|
|
67
|
-
|
|
68
|
-
|
|
69
|
-
|
|
84
|
+
```vue [app/pages/about.vue]
|
|
85
|
+
<script setup lang="ts">
|
|
86
|
+
useHead({
|
|
87
|
+
title: 'About Us',
|
|
88
|
+
meta: [
|
|
89
|
+
{ name: 'description', content: 'Learn more about our company' },
|
|
90
|
+
{ property: 'og:title', content: 'About Us' },
|
|
91
|
+
{ property: 'og:description', content: 'Learn more about our company' },
|
|
92
|
+
],
|
|
93
|
+
})
|
|
94
|
+
</script>
|
|
95
|
+
```
|
|
96
|
+
|
|
97
|
+
### Reactive Meta Tags
|
|
98
|
+
|
|
99
|
+
```vue [app/pages/profile.vue]
|
|
100
|
+
<script setup lang="ts">
|
|
101
|
+
const profile = ref({ name: 'John Doe' })
|
|
102
|
+
|
|
103
|
+
useHead({
|
|
104
|
+
title: computed(() => profile.value.name),
|
|
105
|
+
meta: [
|
|
106
|
+
{
|
|
107
|
+
name: 'description',
|
|
108
|
+
content: computed(() => `Profile page for ${profile.value.name}`),
|
|
109
|
+
},
|
|
110
|
+
],
|
|
111
|
+
})
|
|
112
|
+
</script>
|
|
113
|
+
```
|
|
114
|
+
|
|
115
|
+
### Using a Function for Full Reactivity
|
|
116
|
+
|
|
117
|
+
```vue [app/pages/dynamic.vue]
|
|
118
|
+
<script setup lang="ts">
|
|
119
|
+
const count = ref(0)
|
|
120
|
+
|
|
121
|
+
useHead(() => ({
|
|
122
|
+
title: `Count: ${count.value}`,
|
|
123
|
+
meta: [
|
|
124
|
+
{ name: 'description', content: `Current count is ${count.value}` },
|
|
125
|
+
],
|
|
126
|
+
}))
|
|
127
|
+
</script>
|
|
128
|
+
```
|
|
129
|
+
|
|
130
|
+
### Adding External Scripts and Styles
|
|
131
|
+
|
|
132
|
+
```vue [app/pages/external.vue]
|
|
133
|
+
<script setup lang="ts">
|
|
134
|
+
useHead({
|
|
135
|
+
link: [
|
|
136
|
+
{
|
|
137
|
+
rel: 'stylesheet',
|
|
138
|
+
href: 'https://cdn.example.com/styles.css',
|
|
139
|
+
},
|
|
140
|
+
],
|
|
141
|
+
script: [
|
|
142
|
+
{
|
|
143
|
+
src: 'https://cdn.example.com/script.js',
|
|
144
|
+
async: true,
|
|
145
|
+
},
|
|
146
|
+
],
|
|
147
|
+
})
|
|
148
|
+
</script>
|
|
149
|
+
```
|
|
150
|
+
|
|
151
|
+
### Body and HTML Attributes
|
|
152
|
+
|
|
153
|
+
```vue [app/pages/themed.vue]
|
|
154
|
+
<script setup lang="ts">
|
|
155
|
+
const isDark = ref(true)
|
|
156
|
+
|
|
157
|
+
useHead({
|
|
158
|
+
htmlAttrs: {
|
|
159
|
+
lang: 'en',
|
|
160
|
+
class: computed(() => isDark.value ? 'dark' : 'light'),
|
|
161
|
+
},
|
|
162
|
+
bodyAttrs: {
|
|
163
|
+
class: 'themed-page',
|
|
164
|
+
},
|
|
165
|
+
})
|
|
166
|
+
</script>
|
|
167
|
+
```
|
|
168
|
+
|
|
169
|
+
:read-more{to="/docs/4.x/getting-started/seo-meta"}
|
|
@@ -8,6 +8,8 @@ links:
|
|
|
8
8
|
size: xs
|
|
9
9
|
---
|
|
10
10
|
|
|
11
|
+
`useHydration` is a built-in composable that provides a way to set data on the server side every time a new HTTP request is made and receive that data on the client side. This way `useHydration` allows you to take full control of the hydration cycle.
|
|
12
|
+
|
|
11
13
|
::note
|
|
12
14
|
This is an advanced composable, primarily designed for use within plugins, mostly used by Nuxt modules.
|
|
13
15
|
::
|
|
@@ -16,14 +18,24 @@ This is an advanced composable, primarily designed for use within plugins, mostl
|
|
|
16
18
|
`useHydration` is designed to **ensure state synchronization and restoration during SSR**. If you need to create a globally reactive state that is SSR-friendly in Nuxt, [`useState`](/docs/4.x/api/composables/use-state) is the recommended choice.
|
|
17
19
|
::
|
|
18
20
|
|
|
19
|
-
|
|
21
|
+
## Usage
|
|
20
22
|
|
|
21
23
|
The data returned from the `get` function on the server is stored in `nuxtApp.payload` under the unique key provided as the first parameter to `useHydration`. During hydration, this data is then retrieved on the client, preventing redundant computations or API calls.
|
|
22
24
|
|
|
23
|
-
## Usage
|
|
24
|
-
|
|
25
25
|
::code-group
|
|
26
26
|
|
|
27
|
+
```ts [With useHydration]
|
|
28
|
+
export default defineNuxtPlugin((nuxtApp) => {
|
|
29
|
+
const myStore = new MyStore()
|
|
30
|
+
|
|
31
|
+
useHydration(
|
|
32
|
+
'myStoreState',
|
|
33
|
+
() => myStore.getState(),
|
|
34
|
+
data => myStore.setState(data),
|
|
35
|
+
)
|
|
36
|
+
})
|
|
37
|
+
```
|
|
38
|
+
|
|
27
39
|
```ts [Without useHydration]
|
|
28
40
|
export default defineNuxtPlugin((nuxtApp) => {
|
|
29
41
|
const myStore = new MyStore()
|
|
@@ -41,18 +53,6 @@ export default defineNuxtPlugin((nuxtApp) => {
|
|
|
41
53
|
}
|
|
42
54
|
})
|
|
43
55
|
```
|
|
44
|
-
|
|
45
|
-
```ts [With useHydration]
|
|
46
|
-
export default defineNuxtPlugin((nuxtApp) => {
|
|
47
|
-
const myStore = new MyStore()
|
|
48
|
-
|
|
49
|
-
useHydration(
|
|
50
|
-
'myStoreState',
|
|
51
|
-
() => myStore.getState(),
|
|
52
|
-
data => myStore.setState(data),
|
|
53
|
-
)
|
|
54
|
-
})
|
|
55
|
-
```
|
|
56
56
|
::
|
|
57
57
|
|
|
58
58
|
## Type
|
|
@@ -63,6 +63,12 @@ export function useHydration<T> (key: string, get: () => T, set: (value: T) => v
|
|
|
63
63
|
|
|
64
64
|
## Parameters
|
|
65
65
|
|
|
66
|
-
|
|
67
|
-
|
|
68
|
-
|
|
66
|
+
| Parameter | Type | Description |
|
|
67
|
+
| --- | --- | --- |
|
|
68
|
+
| `key` | `string` | A unique key that identifies the data in your Nuxt application. |
|
|
69
|
+
| `get` | `() => T` | A function executed **only on the server** (called when SSR rendering is done) to set the initial value. |
|
|
70
|
+
| `set` | `(value: T) => void` | A function executed **only on the client** (called when initial Vue instance is created) to receive the data. |
|
|
71
|
+
|
|
72
|
+
## Return Values
|
|
73
|
+
|
|
74
|
+
This composable does not return any value.
|
|
@@ -8,15 +8,68 @@ links:
|
|
|
8
8
|
size: xs
|
|
9
9
|
---
|
|
10
10
|
|
|
11
|
-
|
|
12
|
-
|
|
13
|
-
By default, [`useAsyncData`](/docs/4.x/api/composables/use-async-data) blocks navigation until its async handler is resolved. `useLazyAsyncData` provides a wrapper around [`useAsyncData`](/docs/4.x/api/composables/use-async-data) that triggers navigation before the handler is resolved by setting the `lazy` option to `true`.
|
|
11
|
+
`useLazyAsyncData` provides a wrapper around [`useAsyncData`](/docs/4.x/api/composables/use-async-data) that triggers navigation before the handler is resolved by setting the `lazy` option to `true`.
|
|
14
12
|
|
|
15
13
|
::note
|
|
16
|
-
|
|
14
|
+
By default, [`useAsyncData`](/docs/4.x/api/composables/use-async-data) blocks navigation until its async handler is resolved. `useLazyAsyncData` allows navigation to occur immediately while data fetching continues in the background.
|
|
17
15
|
::
|
|
18
16
|
|
|
19
|
-
|
|
17
|
+
## Usage
|
|
18
|
+
|
|
19
|
+
```vue [app/pages/index.vue]
|
|
20
|
+
<script setup lang="ts">
|
|
21
|
+
const { status, data: posts } = await useLazyAsyncData('posts', () => $fetch('/api/posts'))
|
|
22
|
+
</script>
|
|
23
|
+
|
|
24
|
+
<template>
|
|
25
|
+
<div>
|
|
26
|
+
<div v-if="status === 'pending'">
|
|
27
|
+
Loading...
|
|
28
|
+
</div>
|
|
29
|
+
<div v-else-if="status === 'error'">
|
|
30
|
+
Error loading posts
|
|
31
|
+
</div>
|
|
32
|
+
<div v-else>
|
|
33
|
+
{{ posts }}
|
|
34
|
+
</div>
|
|
35
|
+
</div>
|
|
36
|
+
</template>
|
|
37
|
+
```
|
|
38
|
+
|
|
39
|
+
When using `useLazyAsyncData`, navigation will occur before fetching is complete. This means you must handle `pending` and `error` states directly within your component's template.
|
|
40
|
+
|
|
41
|
+
::warning
|
|
42
|
+
`useLazyAsyncData` is a reserved function name transformed by the compiler, so you should not name your own function `useLazyAsyncData`.
|
|
43
|
+
::
|
|
44
|
+
|
|
45
|
+
## Type
|
|
46
|
+
|
|
47
|
+
```ts [Signature]
|
|
48
|
+
export function useLazyAsyncData<DataT, ErrorT> (
|
|
49
|
+
handler: (ctx?: NuxtApp) => Promise<DataT>,
|
|
50
|
+
options?: AsyncDataOptions<DataT>,
|
|
51
|
+
): AsyncData<DataT, ErrorT>
|
|
52
|
+
|
|
53
|
+
export function useLazyAsyncData<DataT, ErrorT> (
|
|
54
|
+
key: string,
|
|
55
|
+
handler: (ctx?: NuxtApp) => Promise<DataT>,
|
|
56
|
+
options?: AsyncDataOptions<DataT>,
|
|
57
|
+
): AsyncData<DataT, ErrorT>
|
|
58
|
+
```
|
|
59
|
+
|
|
60
|
+
`useLazyAsyncData` has the same signature as [`useAsyncData`](/docs/4.x/api/composables/use-async-data).
|
|
61
|
+
|
|
62
|
+
## Parameters
|
|
63
|
+
|
|
64
|
+
`useLazyAsyncData` accepts the same parameters as [`useAsyncData`](/docs/4.x/api/composables/use-async-data), with the `lazy` option automatically set to `true`.
|
|
65
|
+
|
|
66
|
+
:read-more{to="/docs/4.x/api/composables/use-async-data#parameters"}
|
|
67
|
+
|
|
68
|
+
## Return Values
|
|
69
|
+
|
|
70
|
+
`useLazyAsyncData` returns the same values as [`useAsyncData`](/docs/4.x/api/composables/use-async-data).
|
|
71
|
+
|
|
72
|
+
:read-more{to="/docs/4.x/api/composables/use-async-data#return-values"}
|
|
20
73
|
|
|
21
74
|
## Example
|
|
22
75
|
|
|
@@ -40,8 +93,4 @@ watch(count, (newCount) => {
|
|
|
40
93
|
</template>
|
|
41
94
|
```
|
|
42
95
|
|
|
43
|
-
::warning
|
|
44
|
-
`useLazyAsyncData` is a reserved function name transformed by the compiler, so you should not name your own function `useLazyAsyncData`.
|
|
45
|
-
::
|
|
46
|
-
|
|
47
96
|
:read-more{to="/docs/4.x/getting-started/data-fetching"}
|
|
@@ -8,21 +8,81 @@ links:
|
|
|
8
8
|
size: xs
|
|
9
9
|
---
|
|
10
10
|
|
|
11
|
-
|
|
11
|
+
`useLazyFetch` provides a wrapper around [`useFetch`](/docs/4.x/api/composables/use-fetch) that triggers navigation before the handler is resolved by setting the `lazy` option to `true`.
|
|
12
12
|
|
|
13
|
-
|
|
13
|
+
## Usage
|
|
14
|
+
|
|
15
|
+
By default, [`useFetch`](/docs/4.x/api/composables/use-fetch) blocks navigation until its async handler is resolved. `useLazyFetch` allows navigation to proceed immediately, with data being fetched in the background.
|
|
16
|
+
|
|
17
|
+
```vue [app/pages/index.vue]
|
|
18
|
+
<script setup lang="ts">
|
|
19
|
+
const { status, data: posts } = await useLazyFetch('/api/posts')
|
|
20
|
+
</script>
|
|
21
|
+
|
|
22
|
+
<template>
|
|
23
|
+
<div v-if="status === 'pending'">
|
|
24
|
+
Loading ...
|
|
25
|
+
</div>
|
|
26
|
+
<div v-else>
|
|
27
|
+
<div v-for="post in posts">
|
|
28
|
+
<!-- do something -->
|
|
29
|
+
</div>
|
|
30
|
+
</div>
|
|
31
|
+
</template>
|
|
32
|
+
```
|
|
14
33
|
|
|
15
34
|
::note
|
|
16
35
|
`useLazyFetch` has the same signature as [`useFetch`](/docs/4.x/api/composables/use-fetch).
|
|
17
36
|
::
|
|
18
37
|
|
|
38
|
+
::warning
|
|
39
|
+
Awaiting `useLazyFetch` only ensures the call is initialized. On client-side navigation, data may not be immediately available, and you must handle the `pending` state in your component's template.
|
|
40
|
+
::
|
|
41
|
+
|
|
42
|
+
::warning
|
|
43
|
+
`useLazyFetch` is a reserved function name transformed by the compiler, so you should not name your own function `useLazyFetch`.
|
|
44
|
+
::
|
|
45
|
+
|
|
46
|
+
## Type
|
|
47
|
+
|
|
48
|
+
```ts [Signature]
|
|
49
|
+
export function useLazyFetch<DataT, ErrorT> (
|
|
50
|
+
url: string | Request | Ref<string | Request> | (() => string | Request),
|
|
51
|
+
options?: UseFetchOptions<DataT>,
|
|
52
|
+
): Promise<AsyncData<DataT, ErrorT>>
|
|
53
|
+
```
|
|
54
|
+
|
|
19
55
|
::note
|
|
20
|
-
|
|
56
|
+
`useLazyFetch` is equivalent to `useFetch` with `lazy: true` option set. See [`useFetch`](/docs/4.x/api/composables/use-fetch) for full type definitions.
|
|
21
57
|
::
|
|
22
58
|
|
|
23
|
-
|
|
59
|
+
## Parameters
|
|
60
|
+
|
|
61
|
+
`useLazyFetch` accepts the same parameters as [`useFetch`](/docs/4.x/api/composables/use-fetch):
|
|
62
|
+
|
|
63
|
+
- `URL` (`string | Request | Ref<string | Request> | () => string | Request`): The URL or request to fetch.
|
|
64
|
+
- `options` (object): Same as [`useFetch` options](/docs/4.x/api/composables/use-fetch#parameters), with `lazy` automatically set to `true`.
|
|
65
|
+
|
|
66
|
+
:read-more{to="/docs/4.x/api/composables/use-fetch#parameters"}
|
|
24
67
|
|
|
25
|
-
##
|
|
68
|
+
## Return Values
|
|
69
|
+
|
|
70
|
+
Returns the same `AsyncData` object as [`useFetch`](/docs/4.x/api/composables/use-fetch):
|
|
71
|
+
|
|
72
|
+
| Name | Type | Description |
|
|
73
|
+
| --- | --- |--- |
|
|
74
|
+
| `data` | `Ref<DataT \| undefined>` | The result of the asynchronous fetch. |
|
|
75
|
+
| `refresh` | `(opts?: AsyncDataExecuteOptions) => Promise<void>` | Function to manually refresh the data. |
|
|
76
|
+
| `execute` | `(opts?: AsyncDataExecuteOptions) => Promise<void>` | Alias for `refresh`. |
|
|
77
|
+
| `error` | `Ref<ErrorT \| undefined>` | Error object if the data fetching failed. |
|
|
78
|
+
| `status` | `Ref<'idle' \| 'pending' \| 'success' \| 'error'>` | Status of the data request. |
|
|
79
|
+
| `clear` | `() => void` | Resets `data` to `undefined`, `error` to `undefined`, sets `status` to `idle`, and cancels any pending requests. |
|
|
80
|
+
|
|
81
|
+
:read-more{to="/docs/4.x/api/composables/use-fetch#return-values"}
|
|
82
|
+
|
|
83
|
+
## Examples
|
|
84
|
+
|
|
85
|
+
### Handling Pending State
|
|
26
86
|
|
|
27
87
|
```vue [app/pages/index.vue]
|
|
28
88
|
<script setup lang="ts">
|
|
@@ -48,8 +108,4 @@ watch(posts, (newPosts) => {
|
|
|
48
108
|
</template>
|
|
49
109
|
```
|
|
50
110
|
|
|
51
|
-
::note
|
|
52
|
-
`useLazyFetch` is a reserved function name transformed by the compiler, so you should not name your own function `useLazyFetch`.
|
|
53
|
-
::
|
|
54
|
-
|
|
55
111
|
:read-more{to="/docs/4.x/getting-started/data-fetching"}
|
|
@@ -15,7 +15,7 @@ This composable is available in Nuxt v3.14+.
|
|
|
15
15
|
```ts [signature]
|
|
16
16
|
function useRuntimeHook<THookName extends keyof RuntimeNuxtHooks> (
|
|
17
17
|
name: THookName,
|
|
18
|
-
fn: RuntimeNuxtHooks[THookName] extends HookCallback ? RuntimeNuxtHooks[THookName] : never
|
|
18
|
+
fn: RuntimeNuxtHooks[THookName] extends HookCallback ? RuntimeNuxtHooks[THookName] : never,
|
|
19
19
|
): void
|
|
20
20
|
```
|
|
21
21
|
|
|
@@ -119,7 +119,7 @@ await navigateTo('https://nuxt.com', {
|
|
|
119
119
|
```ts [Signature]
|
|
120
120
|
export function navigateTo (
|
|
121
121
|
to: RouteLocationRaw | undefined | null,
|
|
122
|
-
options?: NavigateToOptions
|
|
122
|
+
options?: NavigateToOptions,
|
|
123
123
|
): Promise<void | NavigationFailure | false> | false | void | RouteLocationRaw
|
|
124
124
|
|
|
125
125
|
interface NavigateToOptions {
|
package/3.api/5.kit/1.modules.md
CHANGED
|
@@ -47,7 +47,7 @@ export function defineNuxtModule<TOptions extends ModuleOptions> (
|
|
|
47
47
|
|
|
48
48
|
export function defineNuxtModule<TOptions extends ModuleOptions> (): {
|
|
49
49
|
with: <TOptionsDefaults extends Partial<TOptions>> (
|
|
50
|
-
definition: ModuleDefinition<TOptions, TOptionsDefaults, true> | NuxtModule<TOptions, TOptionsDefaults, true
|
|
50
|
+
definition: ModuleDefinition<TOptions, TOptionsDefaults, true> | NuxtModule<TOptions, TOptionsDefaults, true>,
|
|
51
51
|
) => NuxtModule<TOptions, TOptionsDefaults, true>
|
|
52
52
|
}
|
|
53
53
|
```
|
|
@@ -8,7 +8,7 @@ links:
|
|
|
8
8
|
size: xs
|
|
9
9
|
---
|
|
10
10
|
|
|
11
|
-
Programmatic usage can be helpful when you want to use Nuxt programmatically, for example, when building a [CLI tool](https://github.com/nuxt/cli) or [test utils](https://github.com/nuxt/
|
|
11
|
+
Programmatic usage can be helpful when you want to use Nuxt programmatically, for example, when building a [CLI tool](https://github.com/nuxt/cli) or [test utils](https://github.com/nuxt/test-utils).
|
|
12
12
|
|
|
13
13
|
## `loadNuxt`
|
|
14
14
|
|
|
@@ -31,7 +31,7 @@ function loadNuxt (loadOptions?: LoadNuxtOptions): Promise<Nuxt>
|
|
|
31
31
|
|
|
32
32
|
## `buildNuxt`
|
|
33
33
|
|
|
34
|
-
Build Nuxt programmatically. It will invoke the builder (currently [@nuxt/vite-builder](https://github.com/nuxt/nuxt/
|
|
34
|
+
Build Nuxt programmatically. It will invoke the builder (currently [@nuxt/vite-builder](https://github.com/nuxt/nuxt/blob/main/packages/vite) or [@nuxt/webpack-builder](https://github.com/nuxt/nuxt/blob/main/packages/webpack)) to bundle the application.
|
|
35
35
|
|
|
36
36
|
### Type
|
|
37
37
|
|
package/3.api/6.nuxt-config.md
CHANGED
|
@@ -2133,7 +2133,7 @@ See [css-loader](https://github.com/webpack/css-loader) for available options.
|
|
|
2133
2133
|
}
|
|
2134
2134
|
```
|
|
2135
2135
|
|
|
2136
|
-
**See**: [esbuild loader](https://github.com/
|
|
2136
|
+
**See**: [esbuild loader](https://github.com/privatenumber/esbuild-loader)
|
|
2137
2137
|
|
|
2138
2138
|
#### `file`
|
|
2139
2139
|
|
|
@@ -39,7 +39,7 @@ If your issue concerns Vue or Vite, please try to reproduce it first with the Vu
|
|
|
39
39
|
|
|
40
40
|
::card-group
|
|
41
41
|
:card{title="Vue SSR on StackBlitz" icon="i-simple-icons-stackblitz" to="https://stackblitz.com/github/nuxt-contrib/vue3-ssr-starter/tree/main?terminal=dev" target="_blank"}
|
|
42
|
-
:card{title="Vue SSR on CodeSandbox" icon="i-simple-icons-codesandbox" to="https://codesandbox.io/
|
|
42
|
+
:card{title="Vue SSR on CodeSandbox" icon="i-simple-icons-codesandbox" to="https://codesandbox.io/p/sandbox/github/nuxt-contrib/vue3-ssr-starter/main" target="_blank"}
|
|
43
43
|
:card{title="Vue SSR Template on GitHub" icon="i-simple-icons-github" to="https://github.com/nuxt-contrib/vue3-ssr-starter/generate" target="_blank"}
|
|
44
44
|
::
|
|
45
45
|
|