Skip to main content

<svelte:boundary>

<svelte:boundary onerror={handler}>...</svelte:boundary>

Cette fonctionnalité a été ajoutée avec la version 5.3.0

Les frontières (boundaries) vous permettent de compartimenter votre application, afin que vous puissiez :

  • fournir une interface à afficher lorsque les expressions await sont en cours de première résolution
  • gérer les erreurs qui se produisent lors du rendu ou lors de l'exécution des effets, et fournir une interface à afficher lorsqu'une erreur se produit

Si une frontière gère une erreur (avec un snippet failed ou un gestionnaire onerror, ou les deux), son contenu existant sera supprimé.

Les erreurs se produisant à l'extérieur du processus de rendu (par exemple, dans les gestionnaires d'évènement ou après un setTimeout ou du travail asynchrone) ne sont pas attrapées par les frontières d'erreur.

Propriétés

Pour que les frontières puissent fonctionner, l'une des propriétés suivantes doit être fournie en props.

pending

Ce snippet sera affiché lors de la création initiale de la frontière, et restera visible tant que les expressions await au sein de la frontière ne sont pas résolues (démo):

<svelte:boundary>
	<p>{await delayed('salut !')}</p>

	{#snippet pending()}
		<p>chargement...</p>
	{/snippet}
</svelte:boundary>

Le snippet pending ne sera pas affiché pour les mises à jour asynchrones suivantes — pour celles-ci, vous pouvez utiliser $effect.pending().

Dans le bac à sable, votre application est rendue au sein d'une frontière ayant un snippet pending vide, afin que vous puissez utiliser await sans avoir à en créer un.

failed

Si un snippet failed est fourni, il sera rendu lorsque l'erreur sera levée au sein d'une frontière, avec l'error et une fonction reset permettant de recréer le contenu (demo).

<svelte:boundary>
	<ComposantFragile />

	{#snippet failed(error, reset)}
		<button onclick={reset}>oups ! essaye encore</button>
	{/snippet}
</svelte:boundary>

Comme avec tout snippet passé à un composant, le snippet failed peut être passé explicitement comme propriété...

<svelte:boundary {failed}>...</svelte:boundary>

... ou implicitement en le déclarant directement dans la frontière, comme montré dans la l'exemple ci-dessus.

onerror

Si une fonction onerror est fournie, celle-ci sera appelée avec les même arguments error et reset que le snippet failed. Cela est utile pour traiter les erreurs via des services de gestion d'erreur...

<svelte:boundary onerror={(e) => report(e)}>
	...
</svelte:boundary>

... ou pour utiliser error et reset en dehors de la frontière elle-même :

<script>
	let error = $state(null);
	let reset = $state(() => {});

	function onerror(e, r) {
		error = e;
		reset = r;
	}
</script>

<svelte:boundary {onerror}>
	<ComposantFragile />
</svelte:boundary>

{#if error}
	<button onclick={() => {
		error = null;
		reset();
	}}>
		oups ! essaye encore
	</button>
{/if}

Si une erreur se produit dans la fonction onerror (ou si vous y levez une erreur), celle-ci sera gérée par une éventuelle frontière parente, si elle existe.

Utiliser tranformError

Par défaut, les frontières n'ont aucun effet sur le serveur — si une erreur se produit lors du rendu, le rendu en entier va échouer.

Depuis la version 5.51, vous pouvez contrôler ce comportement pour les frontières ayant un snippet failed, en exécutant render(...) avec une fonction transformError.

Si vous utilisez Svelte via un framework tel que SvelteKit, vous n'aurez probablement pas un accès direct à l'appel de render(...) — le framework doit configurer transformError à votre place. SvelteKit ajoutera le support de cette fonctionnalité dans un futur proche, via le hook handleError.

La fonction transformError doit renvoyer un objet pouvant être sérialisé en JSON et qui sera utilisé pour rendre le snippet failed. Cet objet sera sérialisé et utilisé pour hydrater le snippet dans le navigateur.

import { 
function render<Comp extends SvelteComponent<any> | Component<any>, Props extends ComponentProps<Comp> = ComponentProps<Comp>>(...args: {} extends Props ? [component: Comp extends SvelteComponent<any> ? ComponentType<Comp> : Comp, options?: {
    props?: Omit<Props, "$$slots" | "$$events">;
    context?: Map<any, any>;
    idPrefix?: string;
    csp?: Csp;
    transformError?: (error: unknown) => unknown | Promise<unknown>;
}] : [component: Comp extends SvelteComponent<any> ? ComponentType<Comp> : Comp, options: {
    props: Omit<Props, "$$slots" | "$$events">;
    context?: Map<any, any>;
    idPrefix?: string;
    csp?: Csp;
    transformError?: (error: unknown) => unknown | Promise<unknown>;
}]): RenderOutput

Only available on the server and when compiling with the server option. Takes a component and returns an object with body and head properties on it, which you can use to populate the HTML when server-rendering your app.

render
} from 'svelte/server';
import
type App = SvelteComponent<Record<string, any>, any, any>
const App: LegacyComponentType
App
from './App.svelte';
const { const head: string

HTML that goes into the <head>

head
, const body: string

HTML that goes somewhere into the <body>

body
} = await
render<SvelteComponent<Record<string, any>, any, any>, Record<string, any>>(component: ComponentType<SvelteComponent<Record<string, any>, any, any>>, options?: {
    props?: Omit<Record<string, any>, "$$slots" | "$$events"> | undefined;
    context?: Map<any, any>;
    idPrefix?: string;
    csp?: Csp;
    transformError?: ((error: unknown) => unknown | Promise<unknown>) | undefined;
} | undefined): RenderOutput

Only available on the server and when compiling with the server option. Takes a component and returns an object with body and head properties on it, which you can use to populate the HTML when server-rendering your app.

render
(const App: LegacyComponentTypeApp, {
transformError?: ((error: unknown) => unknown | Promise<unknown>) | undefinedtransformError: (error: unknownerror) => { // affiche l'erreur d'origine, avec la stack trace... var console: Console

The console module provides a simple debugging console that is similar to the JavaScript console mechanism provided by web browsers.

The module exports two specific components:

  • A Console class with methods such as console.log(), console.error() and console.warn() that can be used to write to any Node.js stream.
  • A global console instance configured to write to process.stdout and process.stderr. The global console can be used without importing the node:console module.

Warning: The global console object's methods are neither consistently synchronous like the browser APIs they resemble, nor are they consistently asynchronous like all other Node.js streams. See the note on process I/O for more information.

Example using the global console:

console.log('hello world');
// Prints: hello world, to stdout
console.log('hello %s', 'world');
// Prints: hello world, to stdout
console.error(new Error('Whoops, something bad happened'));
// Prints error message and stack trace to stderr:
//   Error: Whoops, something bad happened
//     at [eval]:5:15
//     at Script.runInThisContext (node:vm:132:18)
//     at Object.runInThisContext (node:vm:309:38)
//     at node:internal/process/execution:77:19
//     at [eval]-wrapper:6:22
//     at evalScript (node:internal/process/execution:76:60)
//     at node:internal/main/eval_string:23:3

const name = 'Will Robinson';
console.warn(`Danger ${name}! Danger!`);
// Prints: Danger Will Robinson! Danger!, to stderr

Example using the Console class:

const out = getStreamSomehow();
const err = getStreamSomehow();
const myConsole = new console.Console(out, err);

myConsole.log('hello world');
// Prints: hello world, to out
myConsole.log('hello %s', 'world');
// Prints: hello world, to out
myConsole.error(new Error('Whoops, something bad happened'));
// Prints: [Error: Whoops, something bad happened], to err

const name = 'Will Robinson';
myConsole.warn(`Danger ${name}! Danger!`);
// Prints: Danger Will Robinson! Danger!, to err
@seesource
console
.Console.error(message?: any, ...optionalParams: any[]): void (+1 overload)

Prints to stderr with newline. Multiple arguments can be passed, with the first used as the primary message and all additional used as substitution values similar to printf(3) (the arguments are all passed to util.format()).

const code = 5;
console.error('error #%d', code);
// Prints: error #5, to stderr
console.error('error', code);
// Prints: error 5, to stderr

If formatting elements (e.g. %d) are not found in the first string then util.inspect() is called on each argument and the resulting string values are concatenated. See util.format() for more information.

@sincev0.1.100
error
(error: unknownerror);
// ... et renvoie une erreur nettoyée pouvant être affichée à l'utilisateur // dans le sniplet `failed` return { message: stringmessage: 'Une erreur s\'est produite !' }; }; });

Si transformError jette (ou re-jette) une erreur, render(...) va entièrement échouer avec cette erreur.

Les erreurs qui se produisent lors du rendu côté serveur peuvent contenir des informations sensibles dans les champs message et stack. Il est recommandé de caviarder ces informations plutôt que des les envoyer telles quelles au navigateur.

Si la frontière a un gestionnaire onerror, celui-ci sera exécuté lors de l'hydratation avec l'objet d'erreur sérialisé.

Les fonctions mount et hydrate acceptent également une option transformError, qui vaut par défaut la fonction identité. Comme pour render, cette fonction transforme une erreur générée lors du rendu avant qu'elle ne soit passée à un snippet failed ou un gestionnaire onerror.

Modifier cette page sur Github llms.txt