La première version beta de SolidJS 2.0 est sortie la semaine dernière. Ryan Carniato a fait un stream pour expliquer en quoi on passait d'une version sync first à une version async first. Il a notamment présenté plusieurs exemples qui démontrent la simplicité de l'utilisation des expressions asynchrones dans SolidJS 2.0. On va voir ici un cas d'utilisation possible sur la récupération d'une liste paginée.

Spécificités de l'asynchronisme

Quand on récupère une donnée de manière synchrone, on n'a pas de question à se poser, la donnée est disponible et on l'utilise. Pour une donnée asynchrone par contre il y a plusieurs problèmes :

• avant de récupérer la donnée pour la première fois, la donnée n'est pas initialisée
• il y a un temps d'attente avant de récupérer la donnée pendant lequel on peut vouloir afficher un indicateur visuel à l'utilisateur
• quand on met à jour la donnée (par exemple passage de la première à la deuxième page d'une liste) on va en général vouloir continuer d'afficher les données de la première page tant que les données de la deuxième page ne sont pas disponibles mais aussi afficher un indicateur pour dire qu'on est en train de récupérer les données suivantes

Il y a également une problématique de cohérence, si un résultat d'une opération asynchrone dépend d'une donnée synchrone (liée à une saisie par l'utilisateur par exemple) on veut en général n'afficher la nouvelle valeur de la donnée synchrone que lorsque le calcul de la donnée asynchrone est terminé pour avoir une incohérence entre les deux.

Comment cela est géré jusqu'à présent

Jusqu'à présent, le fonctionnement spécifique de l'asynchronisme faisait que l'on avait un traitement différent entre la donnée synchrone et la donnée asynchrone. On a vu par exemple émerger Tanstack Query pour cela. L'arrivée du hook use en React a également permis de simplifier la gestion des données asynchrones.

Au niveau de SolidJS 1.0 on a createSignal pour les données synchrones et createResource pour les données asynchrones.

La gestion des données asynchrones se simplifie au cours du temps grâce à de nouvelles primitives mais on a quand même un code spécifique, c'est en cela que l'on n'est pas async first.

Le changement de paradigme

L'idée avec Solid 2.0 c'est d'avoir un paradigme qui traite les données synchrones et asynchrones de la même manière. L'idée derrière cela c'est de se dire que si j'ai du code qui fonctionne avec des données synchrones, le même code fonctionne aussi avec des données asynchrones.

Dans un des exemple de Ryan on a un code de ce type

function App() {
  const [value, setValue] = createSignal(1);
  const increment = () => setValue((prev) => prev + 1);
  const result = createMemo(() => compute(value()));

  return (
    <div>
      <button type="button" onClick={increment}>{latest(value)}</button>
      <p class={[{ pending: isPending(result) }]}>Result for {value()} = {result().toFixed(3)}</p>
    </div>
  );
}

Ce code fonctionne de la même manière que la fonction compute soit une fonction synchrone ou asynchrone. Dans les deux cas, la fonction createMemo va retourner un type Accessor<number>.

Un point important à noter est que la valeur value ne sera mise à jour que lorsque la propriété dérivée result aura pu être calculée et donc quand compute aura retourné un résultat. L'idée c'est d'avoir une consistance entre toutes les données pour éviter d'afficher un résultat qui ne correspond pas à la valeur courante.

Pour traiter les besoins spécifiques à l'asynchrone Solid va fournir plusieurs éléments

• on a un composant Loading qui correspond au Suspense de React ou de Solid 1.0 qui va afficher un fallback lorsque la donnée n'est pas encore initialisée (au premier appel). Ce fallback ne sera par contre pas affiché quand on récupérera une nouvelle valeur
• le helper isPending va permettre de savoir si un refetch est en cours, dans notre exemple on pourrait faire isPending(result) pour savoir si on est en cours de calcul
• le helper latest(value) va permettre d'avoir accès à la nouvelle valeur de value avant d'avoir la réponse de result, cela permet d'afficher cette valeur dès que l'on clique au niveau du bouton

Cas d'usage : liste paginée

A partir de ce nouveau mode de fonctionnement on peut très facilement implémenter une liste paginée avec le code suivant

const App = () => {
  const [page, setPage] = createSignal(1);
  const result = createMemo(() => getResults(page()));

  return (
    <div>
      <h1>Demo</h1>
      <button disabled={latest(page) === 1} onClick={() => setPage(prev => prev - 1)}>Previous</button>
      Page {latest(page)}
      <button onClick={() => setPage(prev => prev + 1)}>Next</button>
      <h2>Result </h2>
        <Loading fallback="Loading...">
          <div class={[{loading: isPending(result)}]}>
            <For each={result()}>
              {(value) => <p>{value()}</p>}
            </For>
            <p>{result().length} items</p>
          </div>
        </Loading>
    </div>
  );
};

On a automatiquement un loader au premier chargement de la liste puis la classe loading qui sera appliqué à chaque changement de page.

Conclusion

Cet exemple simple présente les apports du nouveau paradigme “Async First” de SolidJS 2.0. On pourra voir par la suite que cela amène d'autres avantages, notamment la possibilité d'initialiser les signaux avec une fonction réactive.

Par rapport à Solid 1.0, on simplifie l'API du framework puisque l'on utilise systématiquement createSignal plutôt que d'utiliser une autre API createResource pour les données asynchrones.

L'intégration de Solid 2.0 avec SolidStart n'est pas encore disponible mais cela veut également dire que createAsync va disparaître et que l'on pourra utiliser createMemo pour appeler une server function.

Voici la procédure que j'ai suivie en me basant sur cette page qui présente la procédure inverse.

Tout d'abord on désactive pipewire

systemctl --user --now disable pipewire pipewire-pulse wireplumber pipewire.socket pipewire-pulse.socket
systemctl --user mask pipewire pipewire-pulse wireplumber

L'icône du son doit alors disparaître de la barre des tâches.

Ensuite on installe et on active pulseaudio

sudo apt install pulseaudio
systemctl --user --now enable pulseaudio.service pulseaudio.socket

Là on vérifie que l'icône du son est bien revenue et on peut lire un fichier audio ou une vidéo qui auparavant posait problème pour vérifier que le problème est bien résolu.

Ensuite on peut supprimer pipewire

sudo apt remove pipewire pipewire-pulse wireplumber
sudo apt autoremove

Pour être sûr de la config on peut utiliser la commande suivante

pactl info

qui doit indiquer Nom du serveur : pulseaudio.

Contexte

Durant ma carrière j'ai toujours été intéressé par le sujet de l'éco-conception mais dans aucun de mes postes je n'ai eu la possibilité de passer du temps pour approfondir le sujet et le mettre en place.

Il y a 4 mois j'ai commencé mon premier projet en freelance from scratch. Je me suis posé la question de la stack que je pourrais utiliser pour avoir dès le départ un projet le plus sobre possible.

Je développe depuis bientôt 15 ans en javascript puis en typescript, principalement dans l'écosystème React depuis 7 ans. Je ne souhaitais par repartir sur une techno complètement nouvelle donc je voulais trouver quelque chose proche de ce que je connais.

L'appli que je développe est à destination des actionnaires de sociétés d'énergie citoyenne. D'un point de vue technique, pas besoin de SEO, c'est une SPA (Single Page Application) des plus classique.

Les critères que je me suis donné :

• limiter l'utilisation du réseau via un bundle le plus petit possible, peu d'assets de petite taille, des appels API efficients
• limiter l'utilisation des ressources sur le serveur via une librairie d'accès à la base de données la plus efficiente possible

Stack retenue

Après quelques recherches et expérimentation j'ai retenu la stack suivante :

• SolidStart comme framework fullstack
• Drizzle pour l'accès à la base de données
• Tailwind et DaisyUI pour la partie design

SolidStart

SolidStart est un framework fullstack basé sur le framework SolidJS.

SolidJS possède deux grands avantages pour moi :

• une proximité avec React au niveau de la syntaxe (JSX, composants, ...)
• de très bonnes performances comparées aux autres framework front existants

SolidJS est plus performant que React car par défaut les composants ne se rendent qu'une seule fois. C'est à nous développeur ensuite d'utiliser les signals pour ajouter de la réactivité là où c'est nécessaire.

En plus de cela SolidStart apporte un framework fullstack très productif notamment grâce aux server functions qui permettent un typage fort de bout en bout et une écriture simplifiée des API. La brique de sérialisation “Seroval” est très performante et pour la mise à jour de données les single flight mutation permettent de réduire les allers retours réseau.

Si vous voulez débuter avec SolidStart, je vous conseille de lire cet article sur les bonnes pratiques qui résume bien les points d'attention notamment pour un ex développeur React.

Drizzle

Pour l'accès aux bases de données j'avais pour habitude d'utiliser un ORM assez classique. En typescript j'ai notamment utilisé MikroORM qui reprend pas mal de concepts d'Hibernate en Java que j'avais utilisé précédemment.

Pour ce projet j'ai décidé de changer pour utiliser Drizzle qui est une surcouche plus fine au dessus de la base de données. L'idée est de s'appuyer plus sur le sql pour diminuer l'overhead de la couche d'accès aux données.

Après plusieurs mois d'utilisation j'avoue être très content de l'outil. Couplé avec SolidStart on arrive à avoir un typage fort de bout en bout qui est très efficace et très pratique.

Tailwind et DaisyUI

Pour la partie design je préfère en règle générale faire directement du CSS lorsque je travaille avec un UI/UX designer pour pouvoir faire du pixel-perfect. Sur ce projet je n'avais pas ce luxe et j'ai donc cherché une librairie de composants plus ou moins clé en main.

Malgré cela je ne voulais pas quelque chose de trop lourd et au final j'ai fait le choix de DaisyUI qui est une surcouche à Tailwind qui est plutôt légère.

Résultats

Pour vous donner une idée de la taille de l'application que j'ai développé, elle comporte environ 75 routes et la base de données contient 35 tables. Je dirais que c'est une application de taille moyenne.

Voici quelques métriques en terme de taille de bundle :

• Le bundle total de l'app gzippé fait 385 ko dont 153 ko pour la librairie apex-charts qui est utilisée uniquement sur quelques pages qui affichent des graphes
• Pour la plupart des pages de l'app la totalité des données transférées sur le réseau est entre 130 et 200 ko
• le css de l'application fait 20 ko compressé

Si j'active la limitation réseau sur le navigateur pour passer en “Regular 3G”, j'ai un temps de chargement des pages autour de 2,5s et une navigation dans l'application qui est fluide.

Côté serveur je n'ai installé aucun outil de monitoring donc c'est dur de quantifier la charge mais mon appli tourne sans problème sur le plus petit VPS Lite d'Infomaniak.

Conclusion

Même si l'eco-conception ne s'arrête pas à la taille du bundle client et aux ressources utilisées côté serveur, limiter ces valeurs est une condition nécessaire pour ensuite pouvoir développer une application qui tournera sur n'importe quel terminal client.

Au niveau de mes choix, j'aurais pu aussi changer de langage et tester par exemple un framework comme Dioxus en Rust mais cela aurait nécessité un apprentissage encore plus en profondeur au détriment de la productivité sans que je sois vraiment capable de mon côté de mesurer les gains obtenus.

Avec le recul de mes 4 premiers mois de développement, les choix que j'ai effectué me paraissent bon pour avoir une application la plus économe en ressources possibles dans l'écosystème typescript. Je trouve que c'est un bon compromis entre sobriété et productivité.

Une fois ces bases mises en place il faut également réfléchir à la façon dont on conçoit l'application pour continuer à avoir une utilisation sobre des ressources par exemple en paginant systématiquement les listes.