Skip to main content

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 :

src/routes/[foo]/[bar]/[baz]/+server
/** @type {import('@sveltejs/kit').RequestHandler<{
	foo: string;
	bar: string;
	baz: string
  }>} */
export async function 
function GET({ params }: {
    params: any;
}): Promise<void>
@type{import('@sveltejs/kit').RequestHandler<{ foo: string; bar: string; baz: string }>}
GET
({ params: anyparams }) {
// ... }
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: stringfoo: string; bar: stringbar: string; baz: stringbaz: 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 :

.svelte-kit/types/src/routes/[foo]/[bar]/[baz]/$types.d
import type * as module "@sveltejs/kit"Kit from '@sveltejs/kit';

type 
type RouteParams = {
    foo: string;
    bar: string;
    baz: string;
}
RouteParams
= {
foo: stringfoo: string; bar: stringbar: string; baz: stringbaz: 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 :

src/routes/[foo]/[bar]/[baz]/+server
/** @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
}) => {
// ... };
src/routes/[foo]/[bar]/[baz]/+page
/** @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>>
@type{import('./$types').PageLoad}
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: PageLoadload: 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.

src/routes/+page
<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 ou jsconfig.json devrait étendre la configuration générée .svelte-kit/tsconfig.json (où .svelte-kit est votre dossier outDir) :

{ "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 :

.svelte-kit/tsconfig
{
	"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 :

.svelte-kit/tsconfig
{
	"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

précédent suivant