Types

Le nom de l'adaptateur, utile pour logguer. Correspond normalement au nom du paquet.

Cette fonction est exécutée après que SvelteKit a compilé votre application.

Checks called during dev and build to determine whether specific features will work in production with this adapter

ts
read?: (details: { config: any; route: { id: string } }) => boolean;

Creates an Emulator, which allows the adapter to influence the environment during dev, build and prerendering

Le type de navigation :

• enter: L'application a été hydratée
• form: L'utilisateur ou utilisatrice a soumis un <form>
• link: La navigation a été déclenchée par un clic sur un lien
• goto: La navigation a été déclenchée par un appel à goto(...) ou une redirection
• popstate: La navigation a été déclenchée par les boutons précédent/suivant du navigateur

Puisque les callbacks afterNavigate sont exécutés après la fin d'une navigation, ils ne seront jamais appelés lorsqu'une navigation décharge la page.

Appelez cette méthode pour empêcher la navigation de démarrer.

Affiche des messages dans la console. log.info et log.minor sont silencieux à moins que l'option logLevel de Vite soit info.

Supprime dir et tout son contenu.

Crée un dossier dir et tout dossier parent nécessaire.

Le contenu du fichier svelte.config.js.

Des informations sur les pages prérendues et ses fichiers statiques, s'il y en a.

Un tableau de toutes les routes (en incluant les routes prérendues).

Crée différentes fonctions qui correspondent à une ou plusieurs routes de votre application.

Trouver l'ensemble des fichiers statiques importés par les scripts serveurs appartenant à routes.

Generate a fallback page for a static webserver to use when no route is matched. Useful for single-page apps.

Génère les variables d'environnement à la compilation disponible dans $env/dynamic/public.

Génère un manifeste côté serveur avec lequel initialiser le serveur SvelteKit.

Résout le chemin vers le fichier name dans outDir, par ex. /path/to/.svelte-kit/my-adapter.

Récupère le chemin résolu complet vers le dossier contenant les fichiers statiques client, incluant le contenu de votre dossier static.

Récupère le chemin résolu complet vers le dossier contenant le code serveur.

Récupère le chemin de l'application en incluant un éventuel chemin configuré par base, par ex. my-base-path/_app.

Écrit les fichiers statiques client dans dest.

Écrit les fichiers prérendus dans dest.

Écrit les fichiers prérendus dans dest.

Copie un fichier ou un dossier.

Compresse les fichiers dans directory avec gzip et brotli, lorsque pertinent. Génère des fichiers .gz et .br au même endroit que les originaux.

Récupère un cookie qui a été précédemment défini avec cookies.set, ou depuis les headers de requête.

Récupère tous les cookies qui ont été précédemment définis avec cookies.set, ou depuis les headers de requête.

Définit un cookie. Ceci va ajouter un header set-cookie à la réponse, mais aussi rendre le cookie disponible via cookies.get ou cookies.getAll pendant la requête courante.

Les options httpOnly et secure valent par défaut true (sauf sur http://localhost, où secure vaut false), et doivent être explicitement désactivées si vous voulez que les cookies soient lisibles par du code JavaScript côté client et/ou transmis via HTTP. L'option sameSite vaut par défaut lax.

Vous devez définir un path pour les cookies. Dans la plupart des cas, vous devriez explicitement définir path: '/' pour rendre le cookie disponible dans toute votre application. Vous pouvez utiliser des chemins relatifs, ou définir path: '' pour rendre le cookie disponible à la page courante et ses pages enfants

Supprime un cookie en définissant sa valeur comme une chaîne de caractères vide et sa date d'expiration à une valeur dans le passé.

Vous devez définir un path pour les cookies. Dans la plupart des cas, vous devriez explicitement définir path: '/' pour rendre le cookie disponible dans toute votre application. Vous pouvez utiliser des chemins relatifs, ou définir path: '' pour rendre le cookie disponible à la page courante et ses pages enfants

Sérialise une paire nom-valeur de cookie en une chaîne de caractères de header Set-Cookie, mais ne l'applique pas à la réponse.

Les options httpOnly et secure valent par défaut true (sauf sur http://localhost, où secure vaut false), et doivent être explicitement désactivées si vous voulez que les cookies soient lisibles par du code JavaScript côté client et/ou transmis via HTTP. L'option sameSite vaut par défaut lax.

Vous devez définir un path pour les cookies. Dans la plupart des cas, vous devriez explicitement définir path: '/' pour rendre le cookie disponible dans toute votre application. Vous pouvez utiliser des chemins relatifs, ou définir path: '' pour rendre le cookie disponible à la page courante et ses pages enfants

A function that is called with the current route config and prerender option and returns an App.Platform object

Le code représentant le statut HTTP, entre 400 et 599.

Le contenu de l'erreur.

La méthode fetch est équivalente à l'API web native fetch, avec quelques fonctionnalités additionnelles :

• Vous pouvez l'utiliser pour faire des requêtes authentifiées sur le serveur, puisqu'elle hérite des headers cookie et authorization de la requête de page.
• Elle peut faire des requêtes relatives sur votre serveur (d'habitude, fetch nécessite une URL avec une origine lorsqu'utilisée dans un contexte serveur).
• Les requêtes internes (par ex. vers des routes +server.js) vont directement vers la fonction concernée si fetch est exécutée sur le serveur, sans la surcharge d'une requête HTTP.
• Pendant le rendu côté serveur, la réponse est capturée et inlinée dans le HTML rendu en utilisant les méthodes text et json de l'objet Response. Notez que les headers ne seront pas sérialisés, à moins d'être inclus explicitement via filterSerializedResponseHeaders
• Pendant l'hydratation, la réponse est lue depuis le HTML, en garantissant la cohérence et évitant une requête réseau supplémentaire.

Vous pouvez en apprendre plus sur les requêtes authentifiées avec cookies ici.

Contient les données renvoyées par la fonction load serveur de votre route (dans +layout.server.js ou +page.server.js), si elle existe.

Si vous avez besoin de définir des headers de réponse, vous pouvez le faire en utilisant cette méthode. Cela est utile si vous souhaitez changer la page à mettre en cache, par exemple :

ts
export async function load({ fetch, setHeaders }) {
Binding element 'fetch' implicitly has an 'any' type.
Binding element 'setHeaders' implicitly has an 'any' type.7031
7031Binding element 'fetch' implicitly has an 'any' type.
Binding element 'setHeaders' implicitly has an 'any' type.
	const url = `https://cms.example.com/articles.json`;
	const response = await fetch(url);

	setHeaders({
		age: response.headers.get('age'),
		'cache-control': response.headers.get('cache-control')
	});

	return response.json();
}

ts
export async function load({ fetch, setHeaders }) {
Binding element 'fetch' implicitly has an 'any' type.
Binding element 'setHeaders' implicitly has an 'any' type.7031
7031Binding element 'fetch' implicitly has an 'any' type.
Binding element 'setHeaders' implicitly has an 'any' type.
	const url = `https://cms.example.com/articles.json`;
	const response = await fetch(url);

	setHeaders({
		age: response.headers.get('age'),
		'cache-control': response.headers.get('cache-control'),
	});

	return response.json();
}

Définir le même header plusieurs fois (même dans des fonctions load différentes) est une erreur – vous pouvez définir un header donné seulement une seule fois. Vous ne pouvez pas ajouter un header set-cookie en même temps que vous utilisez setHeaders – utilisez plutôt l'API cookies dans une fonction load de serveur.

setHeaders n'a pas d'effet lorsque la fonction load est exécutée dans le navigateur.

await parent() renvoie les données des fonctions load des fichiers +layout.js parents. Implicitement, un fichier +layout.js manquant est traité comme une fonction ({ data }) => data, ce qui implique qu'elle va relayer les données des fichiers +layout.server.js parents.

Faites attention à ne pas introduire de "cascade" de chargement accidentelle lorsque vous utilisez await parent(). Si par exemple vous voulez uniquement fusionner les données du parent dans un objet à renvoyer, appelez cette fonction après avoir téléchargé vos autres données.

Cette fonction déclare que la fonction load a comme dépendances une ou plusieurs URLs ou identifiants personnalisés, qui peuvent donc être utilisés avec invalidate() pour déclencher la réexécution de la méthode load.

La plupart du temps vous n'avez pas besoin d'utiliser ceci, puisque fetch appelle depends pour vous – c'est uniquement nécessaire si vous utilisez un client d'API personnalisé qui contourne fetch.

Les URLs peuvent être absolues ou relatives à la page qui est en train d'être chargée, et doivent être encodées.

Les identifiants personnaliés doivent être préfixés avec une ou plusieurs lettres en minuscules suivies d'un : pour satisfaire la spécification URI.

L'exemple suivant vous montre comment utiliser depends pour déclarer une dépendance à un identifiant personnalisé, qui sera invalidé avec invalidate après un clic sur un bouton, déclenchant la réexécution de la fonction load.

ts
let count = 0;
export async function load({ depends }) {
Binding element 'depends' implicitly has an 'any' type.7031Binding element 'depends' implicitly has an 'any' type.
	depends('increase:count');

	return { count: count++ };
}

ts
let count = 0;
export async function load({ depends }) {
Binding element 'depends' implicitly has an 'any' type.7031Binding element 'depends' implicitly has an 'any' type.
	depends('increase:count');

	return { count: count++ };
}

<script>
	import { invalidate } from '$app/navigation';

	export let data;

	const increase = async () => {
		await invalidate('increase:count');
	}
</script>

<p>{data.count}<p>
<button on:click={increase}>Augmenter le compteur</button>

Use this function to opt out of dependency tracking for everything that is synchronously called within the callback. Example:

ts
export async function load({ untrack, url }) {
Binding element 'untrack' implicitly has an 'any' type.
Binding element 'url' implicitly has an 'any' type.7031
7031Binding element 'untrack' implicitly has an 'any' type.
Binding element 'url' implicitly has an 'any' type.
	// Untrack url.pathname so that path changes don't trigger a rerun
	if (untrack(() => url.pathname === '/')) {
		return { message: 'Welcome!' };
	}
}

ts
export async function load({ untrack, url }) {
Binding element 'untrack' implicitly has an 'any' type.
Binding element 'url' implicitly has an 'any' type.7031
7031Binding element 'untrack' implicitly has an 'any' type.
Binding element 'url' implicitly has an 'any' type.
	// Untrack url.pathname so that path changes don't trigger a rerun
	if (untrack(() => url.pathname === '/')) {
		return { message: 'Welcome!' };
	}
}

L'endroit d'où la navigation a été déclenchée

L'endroit vers lequel la navigation est dirigée

Le type de navigation :

• form: Un élément <form> a été soumis
• leave: L'utilisateur ou utilisatrice quitte l'application en fermant l'onglet ou en naviguant vers un document différent
• link: La navigation a été déclenchée par un clic sur un lien
• goto: La navigation a été déclenchée par un appel à goto(...) ou une redirection
• popstate: La navigation a été déclenchée par un navigation avec les boutons retour/suivant du navigateur

Si oui ou non la navigation va déclencher le déchargement de la page (c'est-à-dire pas une navigation client)

Dans les cas d'une navigation via les boutons retour/suivant du navigateur, le nombre d'étapes vers l'avant ou l'arrière de l'historique

Un promesse qui se résout une fois la navigation terminée, et qui est rejetée si la navigation échoue ou est annulée. Dans le cas d'une navigation de type willUnload, la promise ne sera jamais résolue

Les paramètres de la page courante – par ex. un objet { slug: string } pour la route /blog/[slug]

Des informations sur la route courante

ts
id: RouteId;

L'URL de la page courante

Les paramètres de la page cible – pax ex. un objet { slug: string } pour la route /blog/[slug]. Vaut null si la cible ne fait pas partie de votre application SvelteKit (car ne correspond à aucune de vos routes).

Des informations sur la route cible

L'URL vers laquelle la navigation se dirige

Le type de navigation :

• form: L'utilisateur ou utilisatrice a soumis un <form>
• link: La navigation a été déclenchée par un clic sur un lien
• goto: La navigation a été déclenchée par un appel à goto(...) ou une redirection
• popstate: La navigation a été déclenchée par les boutons précédent/suivant du navigateur

Puisque les callbacks onNavigate sont exécutés immédiatement avant une navigation côté client, ils ne seront jamais appelés lorsqu'une navigation décharge la page.

L'URL de la page courante

Les paramètres de la page courante – par ex. un objet { slug: string } pour la route /blog/[slug]

Des informations sur la route courante

ts
id: RouteId;

Le code de statut HTTP pour la page courante

L'objet d'erreur pour la page courante, si pertinent. Rempli grâce aux hooks handleError.

Le résultat de la fusion de toutes les données renvoyées par toutes les fonctions load de la page courante. Vous pouvez typer un dénominateur commun grâce à App.PageData.

L'état de la page, qui peut être manipulé avec les fonctions pushState et replaceState importées depuis $app/navigation.

Rempli uniquement après la soumission d'un formulaire. Voir la section sur les actions de formulaire pour plus d'informations.

Le code représentant le statut HTTP, entre 400 et 599.

L'emplacement vers lequel rediriger.

Définit ou récupère les cookies liés à la requête courante

La méthode fetch est équivalente à l'API web native fetch, avec quelques fonctionnalités additionnelles :

• Vous pouvez l'utiliser pour faire des requêtes authentifiées sur le serveur, puisqu'elle hérite des headers cookie et authorization de la requête de page.
• Elle peut faire des requêtes relatives sur votre serveur (d'habitude, fetch nécessite une URL avec une origine lorsqu'utilisée dans un contexte serveur).
• Les requêtes internes (par ex. vers des routes +server.js) vont directement vers la fonction concernée si fetch est exécutée sur le serveur, sans la surcharge d'une requête HTTP.
• Pendant le rendu côté serveur, la réponse est capturée et inlinée dans le HTML rendu en utilisant les méthodes text et json de l'objet Response. Notez que les headers ne seront pas sérialisés, à moins d'être inclus explicitement via filterSerializedResponseHeaders
• Pendant l'hydratation, la réponse est lue depuis le HTML, en garantissant la cohérence et évitant une requête réseau supplémentaire.

Vous pouvez en apprendre plus sur les requêtes authentifiées avec cookies ici.

L'adresse IP du client, définie par l'adaptateur.

Contient les données personnalisées qui ont été ajoutées à la requête via le hook handle.

Les paramètres de la route courante – par ex. un objet { slug: string } pour la route /blog/[slug].

Des données supplémentaire rendues disponibles via l'adaptateur.

L'objet de la requête originale.

Des informations sur la route courante.

ts
id: RouteId;

Si vous avez besoin de définir des headers de réponse, vous pouvez le faire en utilisant cette méthode. Cela est utile si vous souhaitez changer la page à mettre en cache, par exemple :

ts
export async function load({ fetch, setHeaders }) {
Binding element 'fetch' implicitly has an 'any' type.
Binding element 'setHeaders' implicitly has an 'any' type.7031
7031Binding element 'fetch' implicitly has an 'any' type.
Binding element 'setHeaders' implicitly has an 'any' type.
	const url = `https://cms.example.com/articles.json`;
	const response = await fetch(url);

	setHeaders({
		age: response.headers.get('age'),
		'cache-control': response.headers.get('cache-control')
	});

	return response.json();
}

ts
export async function load({ fetch, setHeaders }) {
Binding element 'fetch' implicitly has an 'any' type.
Binding element 'setHeaders' implicitly has an 'any' type.7031
7031Binding element 'fetch' implicitly has an 'any' type.
Binding element 'setHeaders' implicitly has an 'any' type.
	const url = `https://cms.example.com/articles.json`;
	const response = await fetch(url);

	setHeaders({
		age: response.headers.get('age'),
		'cache-control': response.headers.get('cache-control'),
	});

	return response.json();
}

Définir le même header plusieurs fois (même dans des fonctions load différentes) est une erreur – vous pouvez définir un header donné seulement une seule fois.

Vous ne pouvez pas ajouter un header set-cookie en même temps que vous utilisez setHeaders – utilisez plutôt l'API cookies dans une fonction load de serveur.

L'URL demandée.

Vaut true si la requête vient du client demandant les données de +page/layout.server.js. La propriété url ne contiendra pas dans ce cas les informations internes liées à la requête de données. Utilisez cette propriété si cette distinction est importante pour vous.

Vaut true pour les requêtes +server.js venant de SvelteKit sans avoir généré de requête HTTP au sens propre. Ceci se produit lorsque vous faites depuis le serveur des requêtes fetch venant de la même origine.

Applique des transformations personnalisées au HTML. Si done vaut true, il s'agit du dernier morceau (chunk) de HTML. Les morceaux ne sont pas forcément du HTML bien formé (ils peuvent inclure la balise ouvrante d'un élément mais pas la balise fermante, par exemple), mais ils seront toujours découpés en fonctions de frontières sensibles, comme %sveltekit.head% ou les composants de page ou de layout.

Détermine quels headers doivent être inclus dans les réponses sérialisées lorsqu'une fonction load charge une ressource avec fetch. Par défaut, aucun ne sera inclus.

Détermine quels fichiers doivent être ajoutés à la balise <head> pour les précharger. Par défaut, les fichiers js et css seront préchargés.

propriétés privées

ts
client: NonNullable<BuildData['client']>;

ts
nodes: SSRNodeLoader[];

ts
routes: SSRRoute[];

ts
matchers(): Promise<Record<string, ParamMatcher>>;

ts
server_assets: Record<string, number>;

A map of environment variables

A function that turns an asset filename into a ReadableStream. Required for the read export from $app/server to work

await parent() renvoie les données des fonctions load des fichiers +layout.server.js parents.

Faites attention à ne pas introduire de "cascade" de chargement accidentelle lorsque vous utilisez await parent(). Si par exemple vous voulez uniquement fusionner les données du parent dans un objet à renvoyer, appelez cette fonction après avoir téléchargé vos autres données.

Cette fonction déclare que la fonction load a comme dépendances une ou plusieurs URLs ou identifiants personnalisés, qui peuvent donc être utilisés avec invalidate() pour déclencher la réexécution de la méthode load.

La plupart du temps vous n'avez pas besoin d'utiliser ceci, puisque fetch appelle depends pour vous – c'est uniquement nécessaire si vous utilisez un client d'API personnalisé qui contourne fetch.

Les URLs peuvent être absolues ou relatives à la page qui est en train d'être chargée, et doivent être encodées.

Les identifiants personnaliés doivent être préfixés avec une ou plusieurs lettres en minuscules suivies d'un : pour satisfaire la spécification URI.

L'exemple suivant vous montre comment utiliser depends pour déclarer une dépendance à un identifiant personnalisé, qui sera invalidé avec invalidate après un clic sur un bouton, déclenchant la réexécution de la fonction load.

ts
let count = 0;
export async function load({ depends }) {
Binding element 'depends' implicitly has an 'any' type.7031Binding element 'depends' implicitly has an 'any' type.
	depends('increase:count');

	return { count: count++ };
}

ts
let count = 0;
export async function load({ depends }) {
Binding element 'depends' implicitly has an 'any' type.7031Binding element 'depends' implicitly has an 'any' type.
	depends('increase:count');

	return { count: count++ };
}

<script>
	import { invalidate } from '$app/navigation';

	export let data;

	const increase = async () => {
		await invalidate('increase:count');
	}
</script>

<p>{data.count}<p>
<button on:click={increase}>Augmenter le compteur</button>

Use this function to opt out of dependency tracking for everything that is synchronously called within the callback. Example:

ts
export async function load({ untrack, url }) {
Binding element 'untrack' implicitly has an 'any' type.
Binding element 'url' implicitly has an 'any' type.7031
7031Binding element 'untrack' implicitly has an 'any' type.
Binding element 'url' implicitly has an 'any' type.
	// Untrack url.pathname so that path changes don't trigger a rerun
	if (untrack(() => url.pathname === '/')) {
		return { message: 'Welcome!' };
	}
}

ts
export async function load({ untrack, url }) {
Binding element 'untrack' implicitly has an 'any' type.
Binding element 'url' implicitly has an 'any' type.7031
7031Binding element 'untrack' implicitly has an 'any' type.
Binding element 'url' implicitly has an 'any' type.
	// Untrack url.pathname so that path changes don't trigger a rerun
	if (untrack(() => url.pathname === '/')) {
		return { message: 'Welcome!' };
	}
}

Une chaîne de caractères qui identifie de manière unique un service HTTP (par exemple une fonction serverless) et utile pour dédoublonner. Par exemple, /foo/a-[b] et /foo/[c] sont des routes différentes, mais sont toutes deux représentées par /foo/:param dans un fichier Netlify _redirects, et partagent donc un ID.

Une fonction qui compare la route candidate avec la route courante pour déterminer si elle devrait être groupée avec la route courante.

Cas d'usage :

• Pages de repli : /foo/[c] is une solution de repli pour /foo/a-[b], et /[...catchall] est une solution de repli pour toutes les routes
• Grouper les routes qui partagent une config commune : /foo devraient être déployée sur le réseau edge, /bar et /baz devraient être déployées sur une fonction serverless

Une fonction qui est invoquée une fois que l'entrée a été créée. C'est ici que vous devriez écrire la fonction dans le système de fichiers et générer les manifestes de redirections.

Un dictionnaire de path vers des objets { file }, où un chemin comme /foo correspond à foo.html et un chemin comme /bar/ correspond à bar/index.html.

Un dictionnaire de path vers des objets { type }

Un dictionnaire de redirections rencontrées durant le prérendu.

Un tableau de chemins prérendus (sans les trailing slashs, peu importe la configuration de trailing slash)