Types
Types générés
Les types RequestHandler
et Load
acceptent tous les deux un argument Params
vous permettant de
typer l’objet params
. Par exemple, ce endpoint attend les paramètres foo
, bar
et baz
:
/** @type {import('@sveltejs/kit').RequestHandler<{
foo: string;
bar: string;
baz: string
}>} */
export async function function GET({ params }: {
params: any;
}): Promise<void>
GET({ params: any
params }) {
// ...
}
import type { type RequestHandler<Params extends Partial<Record<string, string>> = Partial<Record<string, string>>, RouteId extends string | null = string | null> = (event: RequestEvent<Params, RouteId>) => MaybePromise<Response>
A (event: RequestEvent) => Response
function exported from a +server.js
file that corresponds to an HTTP verb (GET
, PUT
, PATCH
, etc) and handles requests with that method.
It receives Params
as the first generic argument, which you can skip by using generated types instead.
RequestHandler } from '@sveltejs/kit';
export const const GET: RequestHandler<{
foo: string;
bar: string;
baz: string;
}>
GET: type RequestHandler<Params extends Partial<Record<string, string>> = Partial<Record<string, string>>, RouteId extends string | null = string | null> = (event: RequestEvent<Params, RouteId>) => MaybePromise<Response>
A (event: RequestEvent) => Response
function exported from a +server.js
file that corresponds to an HTTP verb (GET
, PUT
, PATCH
, etc) and handles requests with that method.
It receives Params
as the first generic argument, which you can skip by using generated types instead.
RequestHandler<{
foo: string
foo: string;
bar: string
bar: string;
baz: string
baz: string
}> = async ({ params: {
foo: string;
bar: string;
baz: string;
}
The parameters of the current route - e.g. for a route like /blog/[slug]
, a { slug: string }
object.
params }) => {
// ...
};
Bien sûr, cela est fastidieux à écrire, et moins portable (si vous devez renommer le dossier [foo]
en [qux]
, le type ne reflèterait plus la réalité).
Pour résoudre ce problème, SvelteKit génère des fichiers .d.ts
pour chacun de vos endpoints et
pages :
import type * as module "@sveltejs/kit"
Kit from '@sveltejs/kit';
type type RouteParams = {
foo: string;
bar: string;
baz: string;
}
RouteParams = {
foo: string
foo: string;
bar: string
bar: string;
baz: string
baz: string;
};
export type type RequestHandler = (event: Kit.RequestEvent<RouteParams, string | null>) => MaybePromise<Response>
RequestHandler = module "@sveltejs/kit"
Kit.type RequestHandler<Params extends Partial<Record<string, string>> = Partial<Record<string, string>>, RouteId extends string | null = string | null> = (event: Kit.RequestEvent<Params, RouteId>) => MaybePromise<Response>
A (event: RequestEvent) => Response
function exported from a +server.js
file that corresponds to an HTTP verb (GET
, PUT
, PATCH
, etc) and handles requests with that method.
It receives Params
as the first generic argument, which you can skip by using generated types instead.
RequestHandler<type RouteParams = {
foo: string;
bar: string;
baz: string;
}
RouteParams>;
export type type PageLoad = (event: Kit.LoadEvent<RouteParams, Record<string, any> | null, Record<string, any>, string | null>) => MaybePromise<void | Record<string, any>>
PageLoad = module "@sveltejs/kit"
Kit.type Load<Params extends Partial<Record<string, string>> = Partial<Record<string, string>>, InputData extends Record<string, unknown> | null = Record<string, any> | null, ParentData extends Record<string, unknown> = Record<...>, OutputData extends Record<string, unknown> | void = void | Record<...>, RouteId extends string | null = string | null> = (event: Kit.LoadEvent<Params, InputData, ParentData, RouteId>) => MaybePromise<OutputData>
The generic form of PageLoad
and LayoutLoad
. You should import those from ./$types
(see generated types)
rather than using Load
directly.
Load<type RouteParams = {
foo: string;
bar: string;
baz: string;
}
RouteParams>;
Ces fichiers peuvent être importés dans vos endpoints et pages en tant que fichiers se trouvant dans
le même dossier, grâce à l’option rootDirs
de
votre configuration TypeScript :
/** @type {import('./$types').RequestHandler} */
export async function GET({ params: RouteParams
The parameters of the current route - e.g. for a route like /blog/[slug]
, a { slug: string }
object.
params }) {
// ...
}
import type { type RequestHandler = (event: RequestEvent<RouteParams, string | null>) => MaybePromise<Response>
RequestHandler } from './$types';
export const GET: type RequestHandler = (event: RequestEvent<RouteParams, string | null>) => MaybePromise<Response>
RequestHandler = async ({ params: RouteParams
The parameters of the current route - e.g. for a route like /blog/[slug]
, a { slug: string }
object.
params }) => {
// ...
};
/** @type {import('./$types').PageLoad} */
export async function function load(event: LoadEvent<RouteParams, Record<string, any> | null, Record<string, any>, string | null>): MaybePromise<void | Record<string, any>>
load({ params: RouteParams
The parameters of the current page - e.g. for a route like /blog/[slug]
, a { slug: string }
object
params, fetch: {
(input: RequestInfo | URL, init?: RequestInit): Promise<Response>;
(input: string | URL | globalThis.Request, init?: RequestInit): Promise<Response>;
}
fetch
is equivalent to the native fetch
web API, with a few additional features:
- It can be used to make credentialed requests on the server, as it inherits the
cookie
and authorization
headers for the page request.
- It can make relative requests on the server (ordinarily,
fetch
requires a URL with an origin when used in a server context).
- Internal requests (e.g. for
+server.js
routes) go directly to the handler function when running on the server, without the overhead of an HTTP call.
- During server-side rendering, the response will be captured and inlined into the rendered HTML by hooking into the
text
and json
methods of the Response
object. Note that headers will not be serialized, unless explicitly included via filterSerializedResponseHeaders
- During hydration, the response will be read from the HTML, guaranteeing consistency and preventing an additional network request.
You can learn more about making credentialed requests with cookies here
fetch }) {
// ...
}
import type { type PageLoad = (event: LoadEvent<RouteParams, Record<string, any> | null, Record<string, any>, string | null>) => MaybePromise<void | Record<string, any>>
PageLoad } from './$types';
export const const load: PageLoad
load: type PageLoad = (event: LoadEvent<RouteParams, Record<string, any> | null, Record<string, any>, string | null>) => MaybePromise<void | Record<string, any>>
PageLoad = async ({ params: RouteParams
The parameters of the current page - e.g. for a route like /blog/[slug]
, a { slug: string }
object
params, fetch: {
(input: RequestInfo | URL, init?: RequestInit): Promise<Response>;
(input: string | URL | globalThis.Request, init?: RequestInit): Promise<Response>;
}
fetch
is equivalent to the native fetch
web API, with a few additional features:
- It can be used to make credentialed requests on the server, as it inherits the
cookie
and authorization
headers for the page request.
- It can make relative requests on the server (ordinarily,
fetch
requires a URL with an origin when used in a server context).
- Internal requests (e.g. for
+server.js
routes) go directly to the handler function when running on the server, without the overhead of an HTTP call.
- During server-side rendering, the response will be captured and inlined into the rendered HTML by hooking into the
text
and json
methods of the Response
object. Note that headers will not be serialized, unless explicitly included via filterSerializedResponseHeaders
- During hydration, the response will be read from the HTML, guaranteeing consistency and preventing an additional network request.
You can learn more about making credentialed requests with cookies here
fetch }) => {
// ...
};
Les types de retour des fonctions load
sont alors rendus disponibles via le module $types
en
tant que PageData
et LayoutData
respectivement, tandis que l’union des valeurs de retour de
toutes les Actions
est rendu disponible en tant que ActionData
.
À partir de la version 2.16.0, deux types utilitaires additionnels sont fournis : PageProps
définit data: PageData
ainsi que form: ActionData
(lorsque des actions sont définies), tandis
que LayoutProps
définit data: LayoutData
ainsi que children: Snippet
.
<script>
/** @type {import('./$types').PageProps} */
let { data, form } = $props();
</script>
<script lang="ts">
import type { PageProps } from './$types';
let { data, form }: PageProps = $props();
</script>
Legacy mode
Avant la version 2.16.0:
src/routes/+page<script> /** @type {{ data: import('./$types').PageData, form: import('./$types').ActionData }} */ let { data, form } = $props(); </script>
<script lang="ts"> import type { PageData, ActionData } from './$types'; let { data, form }: { data: PageData, form: ActionData } = $props(); </script>
Avec Svelte 4:
src/routes/+page<script> /** @type {import('./$types').PageData} */ export let data; /** @type {import('./$types').ActionData} */ export let form; </script>
<script lang="ts"> import type { PageData, ActionData } from './$types'; export let data: PageData; export let form: ActionData; </script>
Pour que cela fonctionne, votre fichier
tsconfig.json
oujsconfig.json
devrait étendre la configuration générée.svelte-kit/tsconfig.json
(où.svelte-kit
est votre dossieroutDir
) :
{ "extends": "./.svelte-kit/tsconfig.json" }
tsconfig.json par défaut
Le fichier .svelte-kit/tsconfig.json
généré contient un mélange d’options. Certaines sont générées
programmatiquement en fonction de votre configuration de projet, et ne devraient généralement pas
être écrasées sans bonne raison :
{
"compilerOptions": {
"paths": {
"$lib": ["../src/lib"],
"$lib/*": ["../src/lib/*"]
},
"rootDirs": ["..", "./types"]
},
"include": [
"ambient.d.ts",
"non-ambient.d.ts",
"./types/**/$types.d.ts",
"../vite.config.js",
"../vite.config.ts",
"../src/**/*.js",
"../src/**/*.ts",
"../src/**/*.svelte",
"../tests/**/*.js",
"../tests/**/*.ts",
"../tests/**/*.svelte"
],
"exclude": [
"../node_modules/**",
"../src/service-worker.js",
"../src/service-worker/**/*.js",
"../src/service-worker.ts",
"../src/service-worker/**/*.ts",
"../src/service-worker.d.ts",
"../src/service-worker/**/*.d.ts"
]
}
Les autres sont requises pour que SvelteKit fonctionne correctement, et devraient être laissées telles quelles, à moins que vous sachiez ce que vous êtes en train de faire :
{
"compilerOptions": {
// ce garantit que les types sont explicitement
// importés avec `import type`, ce qui nécessaire
// puisque Svelte/Vite ne peut sinon pas compiler
// les composants correctement
"verbatimModuleSyntax": true,
// Vite compile un module TypeScript à la
// fois, plutôt que de compiler le graphe
// de modules tout entier
"isolatedModules": true,
// Dit à TypeScript qu'il est utilisé uniquement
// pour vérifier le typage
"noEmit": true,
// Ceci garantit qu'à la fois `vite build`
// et `svelte-package` fonctionnent correctement
"lib": ["esnext", "DOM", "DOM.Iterable"],
"moduleResolution": "bundler",
"module": "esnext",
"target": "esnext"
}
}
$lib
Ceci est un simple alias vers src/lib
, ou vers n’importe quel dossier étant défini via l’option
config.kit.files.lib
. Cela permet d’accéder aux composants communs et aux
modules utilitaires sans l’absurdité des ../../../..
.
$lib/server
Un sous-dossier de $lib
. SvelteKit va vous empêcher d’importer tout module se trouvant dans
$lib/server
dans du code exécuté côté client. Voir la section modules réservés au
serveur.
app.d.ts
Le fichier app.d.ts
est l’endroit où sont définis les types d’ambience de votre application, c-à-d
les types qui sont disponibles sans avoir besoin de les importer explicitement.
Le namespace App
fait toujours partie de ce fichier. Ce namespace contient différents types qui
influencent la forme de certaines fonctionnalités de SvelteKit avec lesquelles vous interagissez.
Error
Définit la forme commune des erreurs prévues et imprévues. Les erreurs prévues sont jetées en
utilisant la fonction error
. Les erreurs imprévues sont gérées par les hooks handleError
, qui
devraient renvoyer cette forme.
interface Error {…}
message: string;
Locals
L’interface qui définit event.locals
, qui est accessible dans les hooks serveur
(handle
, et handleError
), les fonctions load
de serveur, et les fichiers +server.js
.
interface Locals {}
PageData
Définit la forme commune des états page.data
et des stores
$page.data
— c’est-à-dire les données partagées entre toutes les
pages.
Les fonctions Load
et ServerLoad
dans les dossiers ./$types
seront restreintes en fonction.
Utilisez des propriétés optionnelles pour les données qui ne sont présentes que sur certaines pages.
N’ajoutez pas de signature d’indice ([key: string]: any
).
interface PageData {}
PageState
La forme de l’objet page.state
, qui peut être manipulé en utilisant les fonctions
pushState
et
replaceState
importées depuis $app/navigation
.
interface PageState {}
Platform
Si votre adaptateur fournit un contexte spécifique à une
plateforme via event.platform
, vous pouvez le
définir ici.
interface Platform {}
Modifier cette page sur Github llms.txt