La version 5 apporte une syntaxe et un système de réactivité revisités. Bien qu'il paraisse très différent au premier abord, vous remarquerez très vite des ressemblances. Ce guide passe en revue les changements de manière détaillée et vous aide à faire votre mise à jour. De plus, nous fournissons également quelques informations sur _pourquoi_ nous avons fait ces changements. Vous n'avez pas besoin de migrer vers la nouvelle syntaxe tout de suite — Svelte 5 continue de supporter la syntaxe de la version 4, et il est possible de mélanger des composants utilisant la nouvelle syntaxe avec des composants utilisant l'ancienne syntaxe. Nous pensons que beaucoup de gens seront capables de mettre à jour Svelte en changeant initialement uniquement quelques lignes de code. Nous proposons également un [script de migration](#Migration-script) qui vous aide avec beaucoup de ces étapes automatiquement. ## Nouvelle syntaxe de réactivité [!VO]Reactivity syntax changes La nouvelle API de runes est au coeur de Svelte 5. Les runes sont simplement des instructions pour le compilateur qui informent Svelte à propos de la réactivité attendue. Syntactiquement, les runes sont des fonctions dont le nom commence par un `$`. ### let -> $state En Svelte 4, une déclaration `let` à la racine d'un composant était implicitement réactive. En Svelte 5 les choses sont plus explicites : une variable est réactive lorsqu'elle a créée avec la rune `$state`. Migrons le compteur ci-dessous en rune en l'entourant d'un `$state` : ```svelte ``` Rien d'autre ne change. `count` est toujours le nombre lui-même, et vous pouvez le lire ou le modifier directement, sans aucun intermédiaire comme `.value` ou `getCount()`. > [!DETAILS] Pourquoi ce changement > Le fait qu'une déclaration `let` à la racine d'un composant soit implicitement réactive > fonctionnait très bien, mais cela impliquait que la réactivité était contrainte — déclarer un > `let` à un autre endroit ne le rendait pas réactif. Cela vous forçait à utiliser des stores > lorsque vous souhaitiez sortir du code d'un composant pour le réutiliser ailleurs. Cela signifiait > également que vous deviez apprendre un modèle de réactivité complètement distinct, et au final > cela se révélait souvent moins simple. Puisque la réactivité est plus explicite avec Svelte 5, > vous pouvez continuer d'utiliser la même API en dehors de la racine des composants. Allez sur le > [tutoriel](/tutorial) pour en apprendre plus. ### $: -> $derived/$effect Avec Svelte 4, une déclaration `$:` à la racine d'un composant pouvait être utilisée pour déclarer une dérivation, c-à-d un état entièrement défini par un calcul utilisant un autre état. Avec Svelte 5, ceci s'écrit en utilisant la rune `$derived` : ```svelte ``` Comme avec `$state`, rien d'autre ne change. `double` est toujours le nombre lui-même, et vous pouvez le lire directement, sans intermédiaire comme `.value` ou `getDouble()`. Une déclaration `$:` pouvait également être utilisée pour créer des effets de bord. Avec Svelte 5, nous pouvons le faire en utilisant la rune `$effect` : ```svelte ``` > [!DETAILS] Pourquoi ce changement > `$:` était un raccourci simple et efficace pour débuter : vous pouviez placer un `$:` devant la > plupart de votre code, et cela fonctionnait. L'intuitivité était également un inconvénient lorsque > votre code devenait de plus en plus complexe, parce que cela devenait difficile de raisonner sur > les liens de réactivité entre les différents morceaux de code. L'intention de ce code était-elle > de créer une dérivation, ou un effet de bord ? Avec `$derived` et `$effect`, vous devez choisir > entre les deux (spoiler alert : 90% du temps vous voulez `$derived`), mais le futur-vous et les > autres développeurs et développeuses de votre équipe vous remercieront. > > Il y avait également quelques inconvénients difficiles à détecter : > > - `$:` ne se mettait à jour que juste avant le rendu, ce qui signifiait que vous pouviez lire des > valeurs périmées entre deux rendus > - `$:` n'était exécuté qu'une seule fois par tick, ce qui impliquait que des déclarations > pouvaient être exécutées moins souvent que vous ne le pensiez > - les dépendances de `$:` étaient déterminées via analyse statique. Ceci fonctionnait dans la > plupart des cas, mais pouvait casser de manière subtile au cours d'un refactor lors duquel les > dépendances sont déplacées dans une fonction et ne sont en conséquence plus visibles > - les déclarations `$:` étaient également ordonnées en utilisant l'analyse statique des > dépendances. Dans certains cas, il pouvait y avoir des égalités et l'ordre en résultait mauvais, > demandant des interventions manuelles. L'ordre pouvait aussi se briser lors d'un refactor qui > rendrait "invisibles" certaines dépendances > > Enfin, cette syntaxe n'était pas vraiment compatible avec TypeScript (notre outillage d'éditeur > devait faire des circonvolutions pour le rendre compatible avec TypeScript), ce qui était bloquant > pour rendre le modèle de réactivité de Svelte vraiment universel. > > `$derived` et `$effect` résolvent tous ces problèmes : > > - ils renvoient toujours la valeur la plus à jour > - ils sont exécutés aussi souvent que nécéssaire pour rester stable > - ils déterminent leurs dépendances lors de l'exécution, et sont donc insensibles aux refactors > - ils exécutent leurs dépendences correctement et sont donc insensibles aux problèmes d'ordre > - ils sont adaptés à l'utilisation de TypeScript ### export let -> $props Avec Svelte 4, les propriétés d'un composant étaient déclarées en utilisant `export let`. Chaque propriété nécessitait une déclaration. Avec Svelte 5, toutes les propriétés sont déclarées avec la rune `$props`, via déstructuration : ```svelte ``` Il y a plusieurs cas dans lesquels la déclaration de propriétés est moins évidente que simplement déclarer quelques `export let` : - vous souhaitez renommer la propriété, par exemple parce que le nom est en conflit avec un identifiant réservé (`class` par ex.) - vous ne savez pas à l'avance à quelles autres propriétés vous attendre - vous souhaitez transférer toutes les propriétés à un autre composant Toutes ces situations nécessitent une syntaxe spéciale avec Svelte 4 : - renommer : `export { klass as class}` - autres propriétés : `$$restProps` - toutes les propriétés : `$$props` Avec Svelte 5, la rune `$props` rend ces situations plus simples sans ajouter de syntaxe spécifique à Svelte : - renommer : utilisez le renommage de propriété `let { class: klass } = $props();` - autres propriétés : utilisez la décomposition `let { foo, bar, ...rest } = $props();` - toutes les propriétés : ne déstructurez pas `let props = $props();` ```svelte ``` > [!DETAILS] Pourquoi ce changement > `export let` était l'un des choix d'API les plus controversés, et il y a eu beaucoup de débats > autour de si vous deviez pensez aux propriétés comme étant `export`ées ou `import`ées. `$props` > n'a pas ce problème. De plus, cette syntaxe est alignée avec les autres runes, dont la philosophie > générale peut se résumer par "toute ce qui est relatif à la réactivité en Svelte est une rune". > > Il y avait également beaucoup de limitations liées à `export let`, qui requiert des API > additionnelles, comme montré plus haut. `$props` réunit toutes ces API en un unique concept > syntactique qui repose énormément sur la syntaxe JavaScript classique de déstructuration. ## Changements sur les évènements [!VO]Event changes La gestion des évènements a été refondue avec Svelte 5. Alors qu'avec Svelte 4 il faut utiliser la directive `:on` pour attacher un gestionnaire d'évènement à un élément, avec Svelte 5 ce ne sont que des propriétés comme n'importe quelles autres (autrement dit, enlevez le `:`) : ```svelte ``` Puisque ce ne sont que des propriétés, vous pouvez utiliser la syntaxe raccourcie... ```svelte ``` ... même si lorsque vous utilisez un gestionnaire d'évènement personnalisé il est généralement recommandé d'utiliser un nom plus descriptif. ### Évènements de composant [!VO]Component events Avec Svelte 4, les composants pouvaient émettre des évènements en créant un dispatcher avec `createEventDispatcher`. Cette fonction est dépréciée avec Svelte 5. À la place, les composants doivent accepter des _props de callback_ — ce qui signifie que vous passez des fonctions comme propriétés à ces composants : ```svelte { size += power---.detail---; if (size > 75) burst = true; }} ---on:---deflate={(power) => { if (size > 0) size -= power---.detail---; }} /> {#if burst} 💥 {:else} 🎈 {/if} ``` ```svelte Puissance de la pompe : {power} ``` ### Remonter des évènements [!VO]Bubbling events Plutôt que d'écrire ` ``` Notez que ceci signifie également que vous pouvez _spread_ les gestionnaires d'évènement sur un élément avec les autres propriétés plutôt que relayer péniblement chaque évènement séparément : ```svelte ``` ### Modificateurs d'évènement [!VO]Event modifiers Avec Svelte 4, vous pouvez ajouter des modificateurs aux gestionnaires d'évènement : ```svelte ``` Les modificateurs sont spécifiques à `on:` et ne sont pas compatibles avec la nouvelle syntaxe de gestion des évènements. L'ajout de choses comme `event.preventDefault()` dans le gestionnaire lui-même est préférable, puisque toute la logique est placée à un seul endroit plutôt que d'être séparée entre gestionnaire et modificateur. Puisque les gestionnaires d'évènements ne sont que des fonctions, vous pouvez créer vos propres wrappers si nécessaire : ```svelte ``` Il y a trois modificateurs — `capture`, `passive` et `nonpassive` — qui ne peuvent pas être exprimés comme des fonctions wrapper, puisqu'ils doivent être appliqués lorsque le gestionnaire d'évènement est lié et non lorsqu'il est exécuté. Pour `capture`, le modificateur s'ajoute au nom de l'évènement : ```svelte ``` Changer l'option [`passive`](https://developer.mozilla.org/fr/docs/Web/API/EventTarget/addEventListener#am%C3%A9lioration_des_performances_de_d%C3%A9filement_avec_les_%C3%A9couteurs_passifs) d'un gestionnaire d'évènement n'est en revanche pas quelque chose à prendre à la légère. Si vous avez un cas d'usage — et ce n'est probablement pas le cas ! — il vous faudra utiliser une action pour ajouter le gestionnaire d'évènement vous-même. ### Gestionnaires multiples [!VO]Multiple event handlers Avec Svelte 4, ceci est possible : ```svelte ``` Les attributs/propriétés dupliquées — ce qui inclut donc maintenant les gestionnaires d'évènement – ne sont pas permis. À la place, faites ceci : ```svelte ``` Lorsque vous "étalez" des props, les gestionnaires d'évènement locaux doivent être appliqués _après_ le spread, ou ils risquent d'être écrasés : ```svelte ``` > [!DETAILS] Pourquoi ce changement > `createEventDispatcher` a toujours été un peu pénible à utiliser : > > - importer la fonction > - appeler la fonction pour obtenir une fonction de dispatch > - exécuter la fonction de dispatch avec une chaîne de caractères et éventuellement une payload > - récupérer la payload en question de l'autre côté via la propriété `.detail`, car l'évènement > lui-même était systématiquement un `CustomEvent` > > Il a toujours été possible d'utiliser des props de callback pour les composants, mais parce qu'il > était nécessaire d'écouter les évènements du DOM avec `on:`, cela avait du sens d'utiliser > `createEventDispatcher` pour les évènements de composant pour garder une consistance syntactique. > Maintenant que nous avons les attributs d'évènement (`onclick`), c'est le contraire : les props de > callback sont maintenant la méthode recommandée. > > La suppression des modificateurs d'évènement est indiscutablement un des changements ressemblant > le plus à un retour en arrière pour celles et ceux qui ont apprécié la syntaxe raccourcie des > modificateurs d'évènement. Étant donné qu'ils ne sont pas utilisés si souvent que ça, nous avons > choisi de privilégier le côté explicite plutôt qu'une surface plus restreinte. Les modificateurs > étaient également inconsistents, puisque la plupart d'entre eux n'étaient utilisables que sur des > éléments DOM. > > L'utilisation de plusieurs gestionnaires pour le même évènement n'est également plus possible, > mais cela était de toutes façon une méthode non-recommandée, car elle compliquait la lecture du > code : s'il y avait beaucoup d'attributs, il devenait difficile de se rendre compte qu'il y avait > deux gestionnaires à moins qu'ils ne soient positionnés juste à côté l'un de l'autre. De plus, > cela laissait entendre que les deux gestionaires étaient indépendants, alors que quelque chose > comme `event.stopImmediatePropagation()` dans `one` empêcherait `two` d'être exécuté. > > En dépréciant `createEventDispatcher` et la directive `on:` en faveur des props de callback et des > propriétés normales d'éléments, cela nous permet de : > > - réduire la courbe d'apprentissage de Svelte > - supprimer du boilerplate, particulièrement autour de `createEventDispatcher` > - supprimer le surcoût de créer des objets `CustomEvent` pour des évènements qui n'ont peut-être > même pas de gestionnaire associé > - ajouter la possibilité de spread les gestionnaires d'évènement > - ajouter la possibilité de savoir quels gestionnaires sont fournis au composant > - ajouter la possibilité d'exprimer si un gestionnaire donné est requis ou optionnel > - augmenter la sécurité du typage (auparavant, il était dans les faits impossible pour Svelte de > garantir qu'un composant n'émettait pas un évènement particulier) ## Des snippets plutôt que des slots [!VO]Snippets instead of slots Avec Svelte 4, du contenu peut être passé aux composants en utilisant des slots. Svelte 5 les remplace par les snippets, qui sont plus puissants et plus flexibles. En conséquence, les slots sont dépréciés par Svelte 5. Ils continuent toutefois de fonctionner, et vous pouvez passer des snippets à un composant qui utilise des slots : ```svelte

``` ```svelte default child content {#snippet foo({ message })} message from child: {message} {/snippet} ``` (L'inverse n'est pas vrai — vous ne pouvez pas passer du contenu slotté à un composant qui utilise des balises [`{@render ...}`](/docs/svelte/@render).) Lorsque vous utilisez des éléments personnalisés, vous devez toujours utiliser `` comme avant. Dans une version future, lorsque Svelte supprimera sa version interne des slots, les slots des éléments personnalisés seront laissés tels quels, c-à-d générant une vraie balise DOM plutôt que de la transformer. ### Contenu par défaut [!VO]Default content Avec Svelte 4, la façon la plus simple de passer un morceau d'interface à un enfant était d'utiliser un ``. Avec Svelte 5, vous pouvez faire cela en utilisant plutôt la prop `children`, qui s'utilise avec `{@render children()}` : ```svelte ------ +++{@render children?.()}+++ ``` ### Contenu générique multiple [!VO]Multiple content placeholders Si vous souhaitiez plusieurs morceaux d'interface génériques, vous deviez utiliser les slots nommés. Avec Svelte 5, vous pouvez plutôt utiliser des props, les nommer comme vous le souhaitez et les afficher avec `{@render ...}` : ```svelte

------ +++{@render header()}+++

------ +++{@render main()}+++

``` ### Remonter des données [!VO]Passing data back up Avec Svelte 4, vouss pouviez passer des données à un `` puis les récupérer avec `let:` dans le composant parent. Avec Svelte 5, les snippets ont désormais cette responsabilité : ```svelte +++{#snippet item(text)}+++ {text} +++{/snippet}+++ ---Pas encore d'éléments--- +++{#snippet empty()} Pas encore d'éléments {/snippet}+++ ``` ```svelte {#if items.length}

------ +++{@render item(entry)}+++

{:else} ------ +++{@render empty?.()}+++ {/if} ``` > [!DETAILS] Pourquoi ce changement > Les slots étaient simples à prendre en main, mais dans les cas d'usage avancés, la syntaxe > devenait de plus en plus confuse et complexe : > > - la syntaxe `let:` n'était pas claire pour beaucoup de gens car elle _crée_ une variable alors > que toutes les autres directives `:` _reçoivent_ une variable > - le scope d'une variable déclarée avec `let:` n'était pas clair. Dans l'example ci-dessus, il > semble que vous puissiez utiliser la prop de slot `item` dans le slot `empty`, mais ce n'est en > réalité pas possible > - les slots nommés devaient être utilisés sur un élément utilisant l'attribut `slot`. Parfois vous > ne vouliez pas créer un élément, et il a donc fallu ajouter l'API `` > - les slots nommés pouvaient aussi être utilisés sur un composant, ce qui changeait la sémantique > de où les directives `let:` sont disponibles (même encore aujourd'hui les mainteneurs du projet > ne se souviennent pas toujours de comment ça fonctionne précisément) > > Les snippets résolvent tous ces problèmes en étant beaucoup clairs et lisibles. Ils sont de plus > plus puissants puisqu'ils vous permettent de définir des sections d'interface que vous pouvez > afficer _partout_, et pas seulement en les passant en props à un composant. ## Script de migration [!VO]Migration script Vous devriez avoir maintenant une idée plus claire des changements apportés, notamment ce que change la nouvelle syntaxe par rapport à l'ancienne. Vous avez probablement également compris que beaucoup de ces migrations sont plutôt techniques et répétitives — des choses que vous n'avez pas envie de faire à la main. Nous sommes d'accord, c'est pourquoi nous fournissons un script de migration pour faire la plupart de ces migrations automatiquement. Vous pouvez migrer votre projet en utilisant `npx sv migrate svelte-5`. Ceci va faire les choses suivantes : - mettre à jour les versions des dépendences principales dans votre `package.json` - migrer votre code pour utiliser les runes (`let` -> `$state` etc.) - migrer les éléments DOM pour qu'ils utilisent les attributs d'évènements (`on:click` -> `onclick`) - migrer les créations de slots pour utiliser les balises de rendu (`` -> `{@render children()}`) - migrer l'utilisation des slots pour utiliser des snippets (`

...

` -> `{#snippet x()}

...

{/snippet}`) - migrer les créations évidentes de composant (`new Component(...)` -> `mount(Component, ...)`) Vous pouvez aussi migrer un seul composant à la fois dans VS Code via la commande `Migrate Component to Svelte 5 Syntax`, ou dans notre bac à sable via le bouton `Migrer`. Tout ne sera pas migré automatiquement, et certaines migrations auront besoin d'un nettoyage manuel a posteriori. Les sections suivantes fournissent plus de détails sur ces situations. ### run Vous remarquerez peut-être que le script de migration convertit certaines de vos déclarations `$:` en une fonction `run` qui est importée depuis `svelte/legacy`. Ceci se produit si le script de migration n'a pas pu déterminer avec certitude si une déclaration devrait être migrée en une rune `$derived`, et en a déduit qu'il s'agissait d'un effet de bord. Dans certains cas il se peut que cela soit faux, et il sera alors recommandé de le modifier manuellement pour utiliser plutôt un `$derived`. Dans d'autres cas cela sera correct, mais puisque les déclarations `$:` sont également exécutées sur le serveur alors que `$effect` non, c'est un changement risqué à faire tel quel. À la place `run` est utilisé comme bouche-trou. `run` reproduit la plupart des caractéristiques de `$:`, en ce qu'il n'est exécuté sur le serveur qu'une seule fois, et est exécuté comme `$effect.pre` sur le client (`$effect.pre` est joué _avant_ que les changements ne soient appliqués au DOM ; dans la plupart des cas vous voudrez utiliser plutôt `$effect`). ```svelte ``` ### Modificateurs d'évènements [!VO]Event modifiers Les modificateurs d'évènements ne sont pas applicables sur les attributs d'évènement (c-à-d que vous ne pouvez pas écrire `onclick|preventDefault={...}`). En conséquence, lorsque vous migrez des directives d'évènement vers des attributs d'évènement, une fonction est nécessaire pour remplacer ces modificateurs. Ces fonctions sont importées depuis `svelte/legacy`, et devraient être remplacées à terme par l'usage, par exemple, de `event.preventDefault()`. ```svelte ``` ### Choses non auto-migrées [!VO]Things that are not automigrated Le script de migration ne convertit pas `createEventDispatcher`. Vous devrez les migrer manuellement. La raison est qu'il est trop risqué de le faire automatiquement, cela pourrait entraîner des incohérences problématiques pour les consommateurs du composant, ce que le script de migration ne peut pas détecter. Le script de migration ne convertit pas `beforeUpdate/afterUpdate`. Il ne le fait pas car il est impossible de déterminer l'intention sous-jacente du code concerné. En règle générale, vous pouvez les migrer en utilisant une combinaison de `$effect.pre` (est exécuté au même moment que l'était `beforeUpdate`) et `tick` (importé depuis `svelte`, qui vous permet d'attendre que les changements soient appliqués au DOM pour exécuter du code). ## Les composants ne sont plus des classes [!VO]Components are no longer classes En Svelte 3 et 4, les composants sont des classes. En Svelte 5 ce sont des fonctions et doivent donc être instanciés différemment. Si vous avez besoin d'instancier manuellement des composants, vous devriez plutôt utiliser `mount` ou `hydrate` (importés depuis `svelte`). Si vous voyez cette erreur en utilisant SvelteKit, essayez d'abord de mettre à jour SvelteKit, car sa version la plus récente fournit le support de Svelte 5. Si vous utilisez Svelte sans SvelteKit, vous aurez certainement un fichier `main.js` (ou similaire) que vous ajuster comme ceci : ```js +++import { mount } from 'svelte';+++ import App from './App.svelte' ---const app = new App({ target: document.getElementById("app") });--- +++const app = mount(App, { target: document.getElementById("app") });+++ export default app; ``` `mount` et `hydrate` ont exactement la même API. La différence est que `hydrate` va récupérer le HTML rendu sur le serveur par Svelte, le placer à l'endroit de sa cible, et l'hydrater. Les deux renvoient un objet avec les exports du composant et potentiellement les accesseurs de propriété (si compilé avec `accessors: true`). En revanche, elles n'ont pas de méthodes `$on`, `$set`, et `$destroy` que vous connaissez peut-être de la précédente API utilisant les classes. Voici leurs remplacements : Pour remplacer `$on`, plutôt que d'écouter les évènements, passez les via la propriété `events` dans l'argument d'options. ```js +++import { mount } from 'svelte';+++ import App from './App.svelte' ---const app = new App({ target: document.getElementById("app") }); app.$on('event', callback);--- +++const app = mount(App, { target: document.getElementById("app"), events: { event: callback } });+++ ``` > [!NOTE] Notez que l'utilisation de `events` n'est pas recommandée — utilisez plutôt des > [callbacks](#Event-changes) Pour remplacer `$set`, utilisez `$state` pour créer un object de propriétés réactives et les manipuler. Si vous faites ceci dans un fichier `.js` ou `.ts`, pensez à ajuster le nom du fichier pour y inclure `.svelte`, c-à-d `.svelte.js` ou `.svelte.ts`. ```js +++import { mount } from 'svelte';+++ import App from './App.svelte' ---const app = new App({ target: document.getElementById("app"), props: { foo: 'bar' } }); app.$set({ foo: 'baz' });--- +++const props = $state({ foo: 'bar' }); const app = mount(App, { target: document.getElementById("app"), props }); props.foo = 'baz';+++ ``` Pour remplacer `$destroy`, utilisez `unmount`. ```js +++import { mount, unmount } from 'svelte';+++ import App from './App.svelte' ---const app = new App({ target: document.getElementById("app"), props: { foo: 'bar' } }); app.$destroy();--- +++const app = mount(App, { target: document.getElementById("app") }); unmount(app);+++ ``` Comme solution bouche-trou, vous pouvez également utiliser `createClassComponent` ou `asClassComponent` (importés depuis `svelte/legacy`) pour garder la même API post-instantiation que Svelte 4. ```js +++import { createClassComponent } from 'svelte/legacy';+++ import App from './App.svelte' ---const app = new App({ target: document.getElementById("app") });--- +++const app = createClassComponent({ component: App, target: document.getElementById("app") });+++ export default app; ``` Si le composant en question n'est pas sous votre contrôle, vous pouvez utiliser l'option de compilateur `compatibility.componentApi` pour obternir une rétro-compatibilité automatique, ce qui implique que le code utilisant `new Component(...)` continuera de fonctionner sans ajustements (notez que ceci rajoute du code supplémentaire pour tous vos composants). Ceci va également ajouter les méthodes `$set` et `$on` pour toutes les instances de composants que vous obtiendrez via `bind:this`. ```js /// svelte.config.js export default { compilerOptions: { compatibility: { componentApi: 4 } } }; ``` Notez que `mount` et `hydrate` ne sont _pas_ synchrones, ce que implique que des choses comme `onMount` n'auront pas été appelées au moment où la fonction termine son exécution et que les blocs de promesses n'auront pas encore été rendus (parce que `#await` attend la fin d'une micro-tâche pour réagir à la potentielle résolution immédiate d'une promesse). Si vous avez besoin de ces garanties, appelez `flushSync` (importé depuis `svelte`) après avoir appelé `mount` ou `hydrate`. ### Changements de l'API serveur [!VO]Server API changes De même, les composants n'ont plus de méthode `render` lorsqu'ils sont compilés pour le rendu côté serveur. Passez plutôt la fonction à `render` importé depuis `svelte/server` : ```js +++import { render } from 'svelte/server';+++ import App from './App.svelte'; ---const { html, head } = App.render({ props: { message: 'salut' }});--- +++const { html, head } = render(App, { props: { message: 'salut' }});+++ ``` Avec Svelte 4, le rendu d'un composant en chaîne de caractères fournissait aussi le CSS pour tous les composants. Avec Svelte 5 ce n'est plus le cas par défaut, car la plupart du temps vous utilisez un outillage qui s'occupe de gérer cela d'une autre manière (SvelteKit par exemple). Si vous avez besoin que `render` vous fournisse le CSS, vous pouvez mettre l'option de compilateur `injected` à `'injected'`, les éléments `