React Hebdo #73: React-Native, Skia, Deno, TypeScript, Jest, SWR, Stately, Relay, Stitches, Solid, App History, TC39...

Un framework React pour Deno qui mise sur la modernité. Support des modules ES, streaming server-side rendering, React 18, pas de bundling, lazy routing… Projet récent (alpha), donc a suivre dans le temps. Pourrait un jour concurrencer Next.js?

Les snapshots Jest sont souvent décriés par les développeurs React expérimentés. Ils testent trop de détail d'implémentation et cassent trop souvent. Cet article décrit les problèmes, et met en avant quelques usages légitimes avec React.

Perso j'aime bien les snapshots Jest, mais j'avoue que j'en ai un usage très limité avec React et le VDOM: je les utilise plutôt coté Node.js pour les messages d'erreur (inline) et les gros state sur lesquels créer des fixtures peut être assez verbeux. Les snapshots Jest doivent faire parti du process de code review. Si vous ne regardez pas le diff, autant s'en passer!

Il existe plusieurs façons de typer les props de ses composants React en TypeScript, en particulier quand un composant en utilise un autre qui a lui même ses propres props. Cet article propose de typer un composant de 3 façons différentes, et analyse les avantages/inconvénients de chaque approche en terme de lisibilité du code.

Retour d'expérience sur la maintenance dans le temps de la webapp Bedrock, commencée en 2014 en React 0.x. Un post complet, et les leçons ne s'appliquent pas qu'a React: automatisations, CI, tests, monitoring, feature flipping, AB testing, gestion des dépendances, de la sécurité, de la dette technique…

William Candillon dévoile une d'API qui permet de faire tourner Skia (moteur 2D derrière Flutter et Chrome) dans React-Native!

C'est déjà le 2eme projet qui propose de porter Skia sur React-Native (après React-Native-Skia). Cette nouvelle solution reste dans la philosophie React, avec plus d'escape hatches, et la possibilité d'utiliser Skia sur une partie de son app seulement sans forcément tout render avec, donc une adoption incrémentale facilitée.

Une API impérative bas niveau pour l'instant (pas encore open-sourcée). J'attends de voir avec impatience ce qui sera construit au dessus. Niveau cross-platform, ça devrait tenir la route également. Sur le web le bundle sera potentiellement plus lourd à cause de CanvasKit (comme pour Flutter).

Voir aussi le thread de Christian Falch avec une vidéo et plusieurs démos. Un élément me semble important: React-Native pourrait être meilleur que Flutter pour mélanger des vues Skia avec des vues natives.

L'équipe React-Native partage sa vision multi-plateforme de sa technologie qui historiquement est plutôt utilisée sur mobile iOS / Android. Le progrès sur une plateforme React-Native peut bénéficier à d'autres plateformes. Il ne faut pas nécessairement voir les plateformes natives comme des concurrents, mais plutôt comme des sources d'inspiration, et React-Native peut être un catalyseur qui permet de propager certaines pratiques d'un écosystème à l'autre.

Des détails intéressants sur l'usage de React-Native sur Desktop et VR.

Un article intéressant qui décrit comment tout l'univers mobile passe progressivement sur un modèle d'UI déclaratif, initié par React-Native.

Donne un bon aperçu de l'univers mobile en 2021: React-Native, Flutter, SwiftUI, Jetpack Compose… Quelques bouts de code qui se ressemblent d'une plateforme à l'autre. Et si le “Learn Once, Write Everywhere” de React pouvait en fait s'élargir à d'autres languages et frameworks?

Je ne partage pas toutes les opinions de l'auteur sur React-Native (voir discussions Twitter). Il n'a pas l'air de trouver un grand intérêt au partage de code entre plateformes, et parle surtout de iOS et Android. Pour autant, on voit de nombreux retours d'expérience qui démontrent bien l'intérêt du code sharing (pas qu'en JS: C++, Kotlin Multiplatform Mobile…

Voir aussi les autres posts de la série Increment sur le dev mobile.

Les SPAs reposent actuellement sur l'API History, mais celle-ci n'a pas été prévue à la base pour les usages qu'on en fait aujourd'hui, et présente de nombreuses limitations. Un exemple: j'ai cherché récemment comment connaitre la “direction” d'un event popstate et je n'ai pas trouvé de solution.

App History est une proposition WICG prévue pour Chrome 95 (flag experimental), et permettrait de combler ces lacunes, en donnant plus de contrôle et d'events pour manipuler l'historique de navigation.

Leur API event.transitionWhile(loadPageAsync()) semble particulièrement intéressante pour avoir un support natif des navigations qui font des requêtes (fetch de bundle JS ou data), en donnant un feedback normalisé à l'utilisateur,. Cela pourrait bien s'intégrer avec React 18 et le pattern render-as-you-fetch.

Sur le même sujet: voir les APIs close watcher et shared elements transition.

De nouvelles proposals ECMAScript progressent. Mes coups de coeur:

Charlie Gerard nous propose une introduction à Solid, un framework qui a de très bons benchmarks et semble intéresser de plus en plus de monde. On peut dire que le code ressemble d'ailleurs beaucoup à (createEffect, createMemo) sauf que le runtime est assez différent: réactif, utilise de vrais noeuds DOM et se base sur des proxys pour tracker les dépendances et updates.