Apprentissage du nouveau système de véactivité Svelte

Donc Svelte v5, la dernière version de ce qui est probablement le meilleur framework front-end existant, a été publiée et elle est très différente de sa version précédente. La principale différence réside dans la manière dont la réactivité des variables est mise en œuvre. Grâce à ces changements, Svelte est devenu plus facile et en même temps un peu plus difficile.

Comme je travaille intensément avec Svelte v5 depuis v5@next.155 dans des projets micro-frontend réels, j'ai décidé d'écrire cette série d'articles pour transmettre mes connaissances acquises pour vous aider comprendre, adopter et potentiellement migrer votre code vers Svelte v5.

Une brève introduction : la réactivité de Svelte v4

Le système de réactivité de Svelte v4 n'est rien de moins qu'une œuvre d'art : Svelte analyse statiquement le code des composants, puis génère du code qui modifie impérativement le DOM à chaque fois que les variables JavaScript classiques changent. Simple, élégant et très performant. Un exemple rapide :

<script lang="ts">
    let clickCount = 0;

    function countClicks() {
        ++clickCount;
    }
</script>

<svelte:document on:click={() => countClicks()} />
<pre class="brush:php;toolbar:false">Clicks inside document: {clickCount}

Ce composant simple ajoute un écouteur d'événement « clic » à l'objet document et compte les clics. Le nombre de clics est affiché en temps réel avec uniquement le code ci-dessus. Incroyable, non ?

Comme tout dans la vie, cependant, ce n’est pas parfait. Rich Harris (le créateur de Svelte) a expliqué les mises en garde, et je ne les détaillerai pas dans cet article. Je n'en mentionnerai qu'un : Code refactor.

La refactorisation du code n'est pas possible

L'une des mises en garde les plus importantes est l'incapacité de transporter ce système de réactivité en dehors du composant. On ne peut pas, par exemple, créer un module réutilisable qui encapsule l'implémentation de la fonction countClicks dans l'exemple.

Étant donné que la réactivité dépend de l'analyse statique, supprimer la fonction et l'insérer dans un module masquera la mutation variable de l'analyseur de code statique, puis la réactivité sera perdue.

Réactivité dans Svelte v5 : Runes

Le terme rune fait référence à un « symbole magique » et est le terme que Svelte a adopté pour nommer les fonctionnels termes « magiques » suivants :

• $état

• $props

• $liable

• $dérivé

• $effet

La réactivité dans Svelte v5 est régie par l'utilisation de ces runes.

Il est important de noter que même s'ils ressemblent à des valeurs R, leur code produit est en réalité des valeurs L. En d’autres termes, ne pensez pas que vous puissiez transmettre un état de variable en variable. Ceci est détaillé un peu plus ci-dessous dans la section $state rune.

Les principaux avantages de ce nouveau système de réactivité sont :

• Possibilité de refactoriser du code réactif en dehors des composants

• Réactivité fine

Le premier signifie que nous pouvons avoir des variables réactives en dehors des composants ; ce dernier signifie que les rendus des composants sont plus ciblés lorsqu'il s'agit de réagir au changement d'état.

La possibilité d'avoir des composants extérieurs à l'état n'est pas abordée dans cet article mais suivez la série car un article à ce sujet viendra.

Une réactivité fine, d'autre part, signifie que Svelte peut désormais savoir quelle propriété a changé dans un objet d'état, et ne restitue (et réexécute les effets et recalcule les valeurs dérivées) que ce qui est affecté par cette propriété spécifique. seulement. Il s'agit dans certains cas d'une amélioration majeure des performances. À titre d'exemple rapide : si un composant de grande table voit une nouvelle ligne ajoutée à ses données, Svelte affichera uniquement la nouvelle ligne. Si la valeur d'une seule cellule de la 3ème ligne change, seule la cellule qui affiche la valeur sera restituée. Est-ce clair maintenant ? J'espère que c'est le cas, mais sinon, contactez-moi dans la section Commentaires.

La rune $state

Cette rune est utilisée pour créer un état réactif. Réécrivons l'exemple de code Svelte v4 ci-dessus :

<script lang="ts">
    let clickCount = 0;

    function countClicks() {
        ++clickCount;
    }
</script>

<svelte:document on:click={() => countClicks()} />
<pre class="brush:php;toolbar:false">Clicks inside document: {clickCount}

Pour obtenir le même résultat que dans Svelte v4, nous avons simplement utilisé $state(0) au lieu de 0.

La règle principale qui régit cette rune est qu'elle ne peut être utilisée que pour initialiser des variables ou des champs de classe, et cela a à voir avec la note importante que vous avez lue il y a une minute : les runes ressemblent à des fonctions syntaxiquement, mais elles ne le sont pas. Le compilateur remplace les runes par du code qui n'est pas compatible avec l'idée de ce que fait une fonction, c'est-à-dire calculer et renvoyer une valeur. Cela signifie que ce qui suit ne crée pas de deuxième variable réactive :

<script lang="ts">
    let clickCount = $state(0);

    function countClicks() {
        ++clickCount;
    }
</script>

<svelte:document onclick={() => countClicks()} />
<pre class="brush:php;toolbar:false">Clicks inside document: {clickCount}

La nature réactive de clickCount n'est pas transférée ou copiée vers secondClickCount en raison de l'utilisation de l'opérateur d'affectation. Si les runes étaient des fonctions, ce qui précède aurait fonctionné, mais ce n'est pas le cas.

Il y a encore une chose importante à mentionner à propos de $state : cela rend sa valeur profondément réactive. Cela signifie que si la valeur est un objet dont les propriétés contiennent des objets, alors les propriétés des objets contenus sont également réactives. Ce modèle s'applique de manière récursive, de sorte que l'ensemble du graphe d'objet est finalement réactif.

La rune $props

Les propriétés des composants devraient être réactives, et Svelte v5 y parvient en utilisant la rune $props.

<script lang="ts">
    let clickCount = $state(0);
    let secondClickCount = clickCount;

    function countClicks() {
        ++clickCount;
    }
</script>

Parce que l'utilisation de TypeScript est essentielle dans un projet, nous commençons par déclarer les propriétés du composant à l'aide d'un type. Les propriétés facultatives sont marquées en ajoutant ? à son nom.

Vient ensuite l'utilisation de la rune, qui est un énoncé déstructurant. L'exemple montre comment attribuer des valeurs par défaut et comment autoriser les propriétés « rest », qui sont n'importe quelle autre propriété. Le composant répartit (applique) ce « reste » de propriétés en tant que propriétés (attributs) sur l'élément HTML span.

Vous pourriez faire let props : Props = $props(); pour définir les propriétés et cela fonctionne, mais vous ne pouvez pas spécifier de valeurs par défaut pour les différentes propriétés, je vous suggère donc de toujours déclarer les propriétés comme indiqué. Je ne saurais pas non plus comment déclarer restProperties sans déstructurer, d'ailleurs.

Si vous avez prêté attention, ce qui précède produit une erreur TypeScript. Après tout, le type Props ne fait aucune mention d’une propriété « reste ». Comment pouvons-nous taper restProps ?

De manière générale, vous pouvez faire des choses comme celles-ci pour autoriser toutes sortes de choses. Cela dépend de vos compétences en TypeScript, je suppose.

Ce qui suit ouvre le type Props pour autoriser tout attribut data-* :

<script lang="ts">
    let clickCount = 0;

    function countClicks() {
        ++clickCount;
    }
</script>

<svelte:document on:click={() => countClicks()} />
<pre class="brush:php;toolbar:false">Clicks inside document: {clickCount}

Celui-ci permet tout :

<script lang="ts">
    let clickCount = $state(0);

    function countClicks() {
        ++clickCount;
    }
</script>

<svelte:document onclick={() => countClicks()} />
<pre class="brush:php;toolbar:false">Clicks inside document: {clickCount}

Mais le plus souvent, il faudrait autoriser les attributs de l'élément HTML qui reçoit restProps, et dans notre exemple, il s'agissait de l'élément HTML span.

Pour ce scénario courant, Svelte v5 fournit des types qui devraient couvrir la plupart des éléments HTML :

<script lang="ts">
    let clickCount = $state(0);
    let secondClickCount = clickCount;

    function countClicks() {
        ++clickCount;
    }
</script>

L'utilisation de ce dernier permettra aux interfaces graphiques comme VS Code de fournir une intelligence précise sur les accessoires (attributs) possibles pour l'élément HTML span. Bien, non ?

Les attributs HTML L'interface est utilisée pour les éléments HTML qui n'ont aucune particularité dans leur liste de propriétés. De nombreux éléments existent cependant. Par exemple, plutôt que de faire HTMLAttributes, importez l'interface HTMLButtonAttributes depuis 'svelte/elements'.

Le dernier détail concerne les valeurs par défaut. Il n'y a vraiment pas grand chose à dire et l'exemple dit tout : la valeur par défaut de l'accessoire d'opération est 'sum'. Si la propriété n'est pas spécifiée lorsque le composant est utilisé, c'est la valeur que la prop prendra.

Si la valeur par défaut souhaitée n'est pas définie, ne spécifiez rien du tout.

La rune $liable

Celle-ci est une rune très spécifique qui ne peut être utilisée que dans les propriétés des composants. Il marque une propriété comme pouvant être liée.

Si vous ne savez pas ou ne vous en souvenez pas, Svelte permet une liaison bidirectionnelle des propriétés. Vue possède également cette fonctionnalité, contrairement à React.

L'utilisation est super simple :

<script lang="ts">
    type Props = {
        data: number[];
        operation?: 'sum', 'avg';
    };

    let {
        data,
        operation = 'sum',
        ...restProps,
    }: Props = $props();

    function sum() {
        return data.reduce((p, c) => p + c);
    }

    function avg() {
        return sum() / data.length
    }
</script>

<span class="amount" {...restProps}>{operation === 'sum' ? sum() : avg()}</span>

<style>
    .amount {
        font-family: monospace;
    }
</style>

Faites toujours en sorte que les propriétés dont les valeurs sont modifiées soient liées, sinon Svelte se plaindra avec un avertissement de console. L'avertissement indique que les composants ne doivent pas modifier un état qui ne leur appartient pas, et que si cela est prévu, alors une liaison doit être utilisée.

Comme le montre l'exemple, on peut spécifier une propriété par défaut via la rune $bindable. L'exemple définit la valeur par défaut de la propriété sur 5.

Mais un défaut a-t-il un sens ici ? Eh bien, oui. Déclarer une propriété comme pouvant être liée ne la rend pas obligatoire.

La Rune dérivée de $

Chaque fois que nous avons besoin de calculer une valeur en utilisant des valeurs provenant d'accessoires ou d'un autre état réactif (qui peuvent changer avec le temps), nous utilisons la rune $derived.

En ramenant l'exemple de composant qui calcule les sommes et les moyennes, nous pouvons le réécrire en utilisant cette rune :

<script lang="ts">
    let clickCount = 0;

    function countClicks() {
        ++clickCount;
    }
</script>

<svelte:document on:click={() => countClicks()} />
<pre class="brush:php;toolbar:false">Clicks inside document: {clickCount}

Nous avons maintenant une nouvelle variable nommée result qui est aussi réactive que son entrée et qui recalculera automatiquement à chaque fois que les données du tableau de données changent. C'est elle-même une variable réactive, donc le modèle (la partie HTML du composant) qui l'utilise sera également mis à jour.

La rune $effect

Cette rune nous permet de spécifier du code arbitraire qui s'exécute chaque fois que les données réactives changent. Pour que cette rune opère sa magie, elle garde une trace des données réactives lues lors de son exécution. Cet inventaire de données réactives est ensuite utilisé pour réactiver l'effet chaque fois qu'un élément de l'inventaire change de valeur.

Le scénario le plus courant consiste probablement à relancer une opération de récupération de données en fonction de la modification des valeurs :

<script lang="ts">
    let clickCount = $state(0);

    function countClicks() {
        ++clickCount;
    }
</script>

<svelte:document onclick={() => countClicks()} />
<pre class="brush:php;toolbar:false">Clicks inside document: {clickCount}

Les opérations asynchrones sont généralement la norme dans les effets lorsque nous ne voulons pas que nos variables $derived tiennent des promesses. Personnellement, cependant et parce qu'il est si facile de travailler avec des promesses dans Svelte, j'utiliserais simplement une valeur $derived. La variante présentée ensuite fait des données une valeur calculée réactive qui tient une promesse :

<script lang="ts">
    let clickCount = $state(0);
    let secondClickCount = clickCount;

    function countClicks() {
        ++clickCount;
    }
</script>

De manière générale, si vous effectuez une combinaison de $state et $effect, vous feriez probablement mieux d'utiliser un $derived. Il existe cependant des exceptions à cette règle, alors considérez-la comme une règle empirique et non comme la Parole Sainte.

Si la récupération de données n'est pas un bon exemple pour $effect, alors qu'est-ce que c'est ? Voyons celui-ci :

<script lang="ts">
    type Props = {
        data: number[];
        operation?: 'sum', 'avg';
    };

    let {
        data,
        operation = 'sum',
        ...restProps,
    }: Props = $props();

    function sum() {
        return data.reduce((p, c) => p + c);
    }

    function avg() {
        return sum() / data.length
    }
</script>

<span class="amount" {...restProps}>{operation === 'sum' ? sum() : avg()}</span>

<style>
    .amount {
        font-family: monospace;
    }
</style>

Il s'agit d'un simple composant de minuterie qui est contrôlé via sa propriété status. La rune $effect est utilisée ici pour appliquer le fonctionnement du minuteur. Pouvez-vous imaginer refactoriser cela en $derived ? À propos, n'essayez pas car elapsed est un accessoire, il ne peut donc pas être $derived et prop en même temps.

Conclusion

Svelte v5 est livré avec un tout nouveau moteur de réactivité orienté vers de meilleures performances dans les rendus et une meilleure refactorisation du code. L'utilisation du nouveau système de réactivité est à la fois simple et complexe : simple car les scénarios courants sont bien couverts par la conception du système, et un peu plus difficile car, par rapport à la v4, le code est devenu un peu plus complexe.

Quoi qu'il en soit, le nouveau système est puissant et s'adapte à la plupart des scénarios avec élégance et efficacité, fournissant des runes pour toutes les possibilités qui sont simples à utiliser, bien qu'un peu étranges au début.

Quelle est la prochaine étape

Cet article n'a couvert que la partie introductive des runes, ainsi que quelques éléments d'expérience personnelle lors de leur utilisation. Il y a d'autres sujets à aborder pour vous aider, chers lecteurs, à avancer plus rapidement avec cette nouvelle interprétation de Svelte, à savoir :

• Connaissance approfondie du fonctionnement de $effect

• Runes avancées ($state.raw, $derived.by, $effect.pre, etc.)

• Remplacement des magasins par un état réactif

• Scénarios hors norme

Bonus : graphiques de performances

Jetez un œil à ces résultats de référence : Résultats interactifs (krausest.github.io)

Maintenant, la liste des frameworks est épouvantable, vous pouvez donc copier le JSON suivant, puis le coller dans la page Web à l'aide du bouton Coller (voir capture d'écran) :

<script lang="ts">
    let clickCount = 0;

    function countClicks() {
        ++clickCount;
    }
</script>

<svelte:document on:click={() => countClicks()} />
<pre class="brush:php;toolbar:false">Clicks inside document: {clickCount}

Au fait, je pense que le simple fait de focaliser la fenêtre et de coller via le clavier fonctionne aussi.

Cela réduit la liste des frameworks aux plus populaires, ou du moins à ceux que je considère comme populaires. Peut-être que vous le savez mieux que moi.

C'est dommage que Svelte v4 ne soit plus disponible dans les charts, mais comme vous pouvez le constater, parmi les frameworks sélectionnés, le top 3 est incontestable : Vanilla JS, Solid et Svelte.

À l'autre extrémité du spectre, il est tout simplement triste de voir React v19 fonctionner si mal. Le compilateur n’était-il pas censé le rendre bien meilleur ? Il semble que cela ait fini par être un effort inutile. Bien sûr, il semble surpasser React v18, mais c'est tout. Je ne sais pas pourquoi Meta continue d'investir de l'argent dans React. Des pensées, ça vous tente ?

Ce qui précède est le contenu détaillé de. pour plus d'informations, suivez d'autres articles connexes sur le site Web de PHP en chinois!