Plus besoin de createResource : l'asynchrone est désormais natif
Solid 2.0, actuellement en Release Candidate, retravaille fondamentalement les opérations asynchrones, en les intégrant comme des citoyens de première classe au sein du graphe réactif. Cela élimine le besoin de la primitive createResource de Solid 1, permettant à des calculs comme createMemo de renvoyer directement des promesses. Le framework comprend et gère désormais nativement les valeurs asynchrones, rationalisant la manière dont fetchUser ou des sources de données similaires s'intègrent dans les flux réactifs.
La suppression de createResource simplifie la logique de récupération des données et nettoie le code des composants. Dans Solid 1, les développeurs géraient les sorties de createResource, ce qui nécessitait des vérifications dispersées de null ou undefined lors de l'accès aux valeurs des ressources. Le retour direct de promesse dans Solid 2 signifie que le graphe réactif gère la disponibilité des données, supprimant ces vérifications et permettant aux composants de ne traiter que des valeurs simples et définies.
Les primitives de frontière (boundary) ont également été réarchitecturées pour s'aligner sur le nouveau modèle asynchrone, améliorant ainsi l'expérience des développeurs et des utilisateurs. Suspense est remplacé par la frontière Loading, qui affiche des fallbacks spécifiquement en cas d'absence initiale de données. ErrorBoundary devient Errored, principalement un changement de nom avec des remaniements sous-jacents, et SuspenseList devient Reveal.
Cette approche raffinée des frontières améliore considérablement l'expérience utilisateur. Contrairement à d'autres frameworks qui bloquent l'interface utilisateur lors de la consommation de promesses, dans Solid 2, le framework consomme les promesses dès leur création dans son graphe et ne bloque que là où la valeur est lue. Cela permet à l'interface utilisateur de se mettre à jour immédiatement à mesure que chaque donnée devient disponible, plutôt que d'attendre que toutes les requêtes soient terminées. isPending suit les récupérations de données ultérieures sans détruire l'interface utilisateur.
Une expérience développeur radicalement plus propre
Solid 2.0 affine considérablement l'expérience développeur pour les mutations de données et les effets. Un nouveau flux de mutation introduit la primitive action, qui définit un cycle de vie clair pour les mises à jour. Associé à createOptimistic et createOptimisticStore, ce système permet une restauration automatique de l'interface utilisateur : les changements optimistes locaux sont transitoires, disparaissant si un appel API échoue et rétablissant l'interface utilisateur à l'état faisant autorité du serveur.
La gestion des Store est simplifiée car la mutation directe devient le comportement par défaut. Ce changement supprime le besoin de la fonction produce et déprécie createMutable, permettant aux développeurs de modifier directement les brouillons de store. L'assistant storePath reste disponible pour des cas d'utilisation hérités spécifiques.
createEffect reçoit une refonte majeure, se divisant en deux fonctions distinctes. La première, une phase de 'calcul' suivie, définit les dépendances. La seconde, une phase d' 'application' non suivie, exécute l'effet secondaire en recevant la valeur calculée. Ce changement architectural élimine l'assistant on et permet de définir l'option defer directement sur l'effet.
Le nettoyage des effets évolue également. La fonction apply renvoie désormais directement sa logique de nettoyage, rationalisant la gestion des ressources. onMount a été remplacé par onSettled, qui ne se déclenche qu'une fois que toutes les opérations asynchrones dans sa portée sont résolues, renvoyant de la même manière sa fonction de nettoyage. La primitive createComputed est supprimée, sa fonctionnalité étant désormais couverte par createMemo ou le nouvel effet divisé.
La grande simplification du JSX
Solid 2.0 simplifie considérablement la syntaxe JSX, réduisant les idiomes spécifiques au framework. La prop classList a été entièrement supprimée ; la prop class accepte désormais directement des chaînes de caractères, des objets ou des tableaux. Cela permet un style conditionnel plus intuitif et dynamique sans nécessiter de concaténation manuelle de chaînes ou de manipulation de tableaux.
La gestion des attributs s'aligne également davantage sur le HTML natif. Les préfixes attr: et bool:, précédemment utilisés pour la liaison explicite d'attributs et de propriétés booléennes, ne sont plus nécessaires. Ce changement standardise la déclaration des attributs, supprimant une couche de syntaxe spécifique à Solid pour les attributs HTML courants.
Les espaces de noms de gestion d'événements, tels que on: et onCapture:, ont été supprimés. Les événements sont désormais gérés à l'aide de props camelCase standard comme onClick ou onInput, reflétant les modèles de développement web conventionnels. La directive use: a également été remplacée par des callbacks ref empilables, offrant une méthode plus flexible et composable pour les comportements d'éléments personnalisés et les hooks de cycle de vie.
Le rendu de liste a été simplifié. Le composant dédié Index n'est plus disponible, sa fonctionnalité de liste non indexée étant désormais intégrée dans <For keyed={false}>. De plus, un nouveau composant Repeat a été introduit pour rationaliser le rendu basé sur le comptage, offrant un moyen déclaratif de rendre un bloc de JSX un nombre spécifié de fois. Apprenez-en plus sur ces changements et d'autres dans l'article de blog Solid 2.0 RC: The Big <Reveal> - SolidJS.
Cet article vous plaît ? Recevez-en un comme celui-ci chaque matin.
un e-mail par jour · désinscription en deux clics · aucun traqueur tiers
Le compilateur qui a tué le méta-framework
Solid 2 intègre un nouveau compilateur basé sur Rust, construit sur le projet haute performance Oxc. Cette chaîne d'outils repensée améliore considérablement les performances de build du framework. Les benchmarks internes indiquent des vitesses de compilation allant de 20x à plus de 350x plus rapides que le précédent compilateur basé sur JavaScript de Solid 1, se traduisant directement par des cycles de développement plus rapides et des builds de projet plus efficaces.
Le plugin Vite mis à jour introduit un 'mode start' puissant, offrant aux développeurs une construction d'application complète prête à l'emploi. Ce mode prend en charge à la fois le rendu côté client uniquement et les capacités complètes de rendu côté serveur (SSR). Il intègre des fonctionnalités clés comme les fonctions serveur directement dans l'outillage du framework, éliminant le besoin de packages séparés et rationalisant la configuration du projet pour diverses cibles de déploiement.
Cet outillage intégré et puissant rend le méta-framework séparé SolidStart redondant. Les conventions établies de SolidStart, y compris ses fonctions serveur et sa couche de service, ont été absorbées directement dans le cœur de Solid ou son plugin de compilation. Ce mouvement stratégique consolide l'écosystème de développement, intégrant les modèles architecturaux éprouvés et les capacités full-stack de SolidStart directement dans le framework principal, simplifiant ainsi l'expérience globale du développeur.
Questions fréquemment posées
Quel est le plus grand changement dans Solid 2.0 ?
L'innovation principale consiste à faire des opérations asynchrones une fonctionnalité de premier ordre du graphe réactif. Cela permet aux calculs de renvoyer directement des promesses, supprimant le besoin de primitives spéciales comme createResource.
SolidStart est-il abandonné ?
Oui, SolidStart est retiré en tant que méta-framework séparé. Ses fonctionnalités clés, comme le rendu côté serveur et les fonctions serveur, ont été intégrées directement dans le plugin Vite principal de Solid 2.0 via un nouveau 'mode start'.
Comment Solid 2 gère-t-il la récupération de données sans createResource ?
Les calculs comme createMemo peuvent désormais renvoyer directement des promesses. Le système réactif comprend et gère automatiquement l'état asynchrone, simplifiant la logique de récupération de données et le code des composants.
Solid 2 est-il plus rapide à compiler ?
Oui, considérablement. Solid 2 introduit une nouvelle chaîne d'outils de compilation écrite en Rust, dont les benchmarks montrent qu'elle est plus de 20 fois plus rapide, avec certains tests atteignant jusqu'à 355 fois plus de rapidité.
Qu'est-ce qui remplace Suspense dans Solid 2 ?
La limite Suspense a été remplacée par Loading. Loading n'affiche un élément de secours que pour la récupération initiale des données, tandis que les récupérations ultérieures peuvent être suivies avec isPending sans démonter l'interface utilisateur existante.