SolidJS - C'est quoi?

Lorsque vous lisez du code SolidJS, ça ressemble beaucoup à React. Un composant est une fonction qui renvoie du code JSX. Si vous êtes un tant soit peu familier avec React, vous pouvez lire le code SolidJS et avoir une bonne idée de ce qui se passe. En fait, le code suivant est valable à la fois dans React et Solid :

function MyComponent(props) {
  return <div>Hello {props.name}</div> ;
}
<MyComponent name="Solid" /> ;

Et c'est une bonne chose. Il y a déjà suffisamment de frameworks différents, chacun poussant sa propre syntaxe. Et React est le standard. C’est agréable d'être en terrain connu.

Sauf que ce n'est pas le cas.

Car les hooks - qui sont l'épine dorsale de la logique métier de React - n'existent même pas dans Solid JS.

Svelte ne dispose pas d'un hook useState. Au lieu de cela, il s'appuie sur des "signaux". Qu'est-ce qu'un signal ?

Dans Solid, les signaux sont initialisés comme ceci :

const [count, setCount] = createSignal(0) ;

Compte tenu de la syntaxe familière, il est facile d'imaginer que createSignal n'est qu'une variante de "useState" de React. Et dans un sens, les deux servent à résoudre le même problème : suivre l'état de l'application à travers les différentes exécutions des fonctions du composant.

Quelle est donc la différence entre les signaux de SolidJS et les hooks useState de React ?

Le premier indice quand à la différence, est que le premier élément renvoyé par createSignal (donc "count", dans l'exemple ci-dessus) est une fonction.

Le site Web de Solid JS indique : "Les signaux sont des émetteurs d'événements qui contiennent une liste d'abonnements".

Qu'est-ce que cela signifie dans la pratique ?

La documentation indique également que les fonctions des composants "sont appelées une fois et cessent ensuite d'exister". Elles "existent pour organiser votre code et pas grand-chose d'autre".

Ainsi, malgré les similitudes dans la façon dont le code est écrit, on a l'impression que les mécanismes sous-jacents sont très différents.

React suit les changements d'état dans l'arbre des composants en utilisant un DOM virtuel. Puis React rend à nouveau l'arbre en fonction de l'endroit où les changements se produisent dans l'arbre.

Et les fonctions du composant sont appelées à plusieurs reprises. Le composant entier, et ses enfants, sont rendus à nouveau chaque fois qu'une partie de son état change.

Solid, quant à lui, suit quelle partie de l'interface utilisateur dépend de quoi. Et il met à jour cette partie et rien d'autre.

Et cela semble très familier. Ça me rappèle Svelte.

Svelte prétend être le framework qui disparaît. Au lieu de comparer les changements d'état dans un DOM virtuel (comme le font React et d'autres), il surcharge la syntaxe JavaScript pour suivre les dépendances.

En ce sens, il s'agit avant tout d'un compilateur.

Et parce qu'il sait quelle partie de l'interface dépend de quelle variable, il est d’un précision chirurgicale dans ses mises à jour.

Ce que Solid JS fait ressemble beaucoup à cela : les parties de l'interface qui changent sont branchées sur des écouteurs d'événements, des “event listeners”.

Les effets de bord (l’équivalents, en gros, de useEffect) se branchent eux-mêmes sur ces écouteurs d'événements.

Alors pourquoi ne pas utiliser Svelte ou React, au lieu de se tourner vers un (relativement) nouvel arrivant ?

Pour moi (et ce n'est peut-être qu'une question de goût), Svelte ressemble trop à de la magie. Il ressemble à JavaScript, mais le compilateur y ajoute la magie noire de gestion des interdépendances.

Solid, en revanche, est plus logique que Svelte. Il s'agit simplement d'écouteurs d'événements intelligemment organisés, et non d'un compilateur magique.

Les écouteurs d'événements, je connais, je comprends et je fais confiance. Les compilateurs qui font des choses étranges à mon code... pas vraiment.

Quand on y pense, Solid a même plus de sens que React. Les erreurs que j'ai vu les développeurs juniors faire montrent qu'ils n'ont pas saisi quand les composants fonctionnels sont appelés ou comment l'état est géré.

Et dans un sens, c'est ce qui est le plus difficile avec Solid JS.

Les concepts que j'ai appris avec React, qui se sont ancrés dans ma façon de coder, sur la façon de gérer l'état et le rendu, ne se transposent pas bien dans Solid JS. Je n'ai pas besoin de m'inquiéter de la fréquence d'appel des composants - car ils ne sont appelés qu'une seule fois.

Dans ces deux cas, dans la façon dont Solid met en œuvre la réactivité et dans la façon dont il gère le rendu HTML, Solid semble plus sain que ses "parents", Svelte et React.

Tout cela se combine pour produire un code efficace et rapide. Solid JS obtient un score très élevé dans le benchmark des frameworks JavaScript. Il est très bien considéré dans l'enquête State of JavaScript. Et il ne pèse que 7 kb.

Alors pourquoi n'utiliserai-je pas Solid JS tout de suite ?

Eh bien, une partie du problème est que Solid JS n'est tout de même pas React. Et beaucoup de projets dans lesquels je suis impliqué ont déjà une grande base de code React.

Les personnes qui travaillent sur ces projets connaissent React et ne connaissent pas Solid.

Mais j'ai le sentiment qu'ici et là, là où React posait des problèmes de performance, sur des projets où je peux travailler seul, je vais saupoudrer un peu de Solid JS ici et là.

Et qui sait, peut-être qu'un jour je l'utiliserai exclusivement.

Parce que j'aime la façon dont Svelte gère la réactivité, mais je ne suis pas un fan de la magie de son compilateur.

Et j'aime la syntaxe JSX et la simplicité de React, mais j'ai vu trop de gens se faire piéger par un comportement qu'ils ne comprennent pas.

Et Solid JS semble pouvoir réunir le meilleur des deux mondes, d'une manière qui est à la fois simple, saine et ... solide.