Un article sur l'utilisation de React Context dans une app pour partager facilement des informations entre les composants plutôt que les passer dans les props.
L'utilisation est un peu complexe et s'apparente à de l'injection de dépendances.
On fournit les contextes en encapsulant l'application dans des balises donc attention à l'utilisation de plusieurs contextes qui s'encapsulent entre eux et réintroduisent du couplage.
// ContainerContext a besoin de LangContext
<LangContext.Provider value={translate}>
<ContainerContext.Provider value={findTasks}>
<TodoList/>
</ContainerContext.Provider>
</LangContext.Provider>
Une librairie de composants React près à l'emploi pour faire développer une application.
Le design est très épuré je trouve
Un article d'investigation puis de correction de problèmes de performances sur un grosse application React utilisant les Hooks.
L'auteur d'une lib de CSS in JS pour React explique les désavantages de ce fonctionnement.
Les deux principaux désavantages sont le poids supplémentaire des libs nécessaires et l'impact non négligeable sur les performances de rendu.
Après la lib offre quand même une DX très confortable donc à chacun de faire ses compromis.
(Merci Ludo pour le partage)
Un article de fond sur l'évolution du développement frontend.
L'article commence par un historique du frontend:
- Pages dynamique CGI : PHP
- AJAX : JQuery, Flash
- Split frontend/backend : Backbone
- Two way binding : Angular
- JAMStack: Gatbsy, Next
- Components: React, Vue
Le frontend s'est tellement complexifié qu'on atteint des limites en terme de coût de manipulation du DOM (résolu par le Virtual DOM) mais également en terme de traffic réseau et du rendering des éléments d'une mage qui peuvent se bloquer entre eux (charger du CSS par exemple)
L'auteur revient sur les différentes innovations mises en place chez Facebook avec React:
- Optimizing runtime costs: Virtual DOM, CSS avec Stylex
- Optimizing the network: Relay, GraphQL
- Optimizing Javascript bundles: Tree shaking (Facebook utilisent carrément une IA !)
Les différents framework du marché sont passé en revue: React, Svelte, Vue, Solid, Astro, Marko, Fresh, Next, Remix et Qwik
Pour moi le plus important est cette phrase de l'auteur
It’s a good reminder that if you’re on the bleeding edge, you are usually the one bleeding. Defaulting to “boring” technologies, ones you are familiar with, and being a late adopter is often a great choice.
La morale c'est qu'il faut choisir son framework en fonction de ses besoins actuels et faire très attention aux choix techniques pour des projets long termes.
L'article parle des inconvénients de React. (c'est l'auteur de React Admin)
Pour l'auteur, les formulaires sont compliqués à écrire correctement à cause d'un trop haut niveau d'abstraction.
De son point de vue, les hooks ont amené un niveau supplémentaire de complexité sur des parties métiers qui était déjà gérées correctement par Redux.
Il continue sur d'autres points en donnant toujours des exemples voir des comparaisons avec d'autres framework.
Je partage totalement cet opinion sur Typescript du point de vue du développeur de framework.
Quand on est simplement utilisateur, on est content d'utiliser les types et on veut en voir partout.
Quand on doit écrire ces types, c'est rapidement un casse-tête assez important si on veut le faire correctement!
Regardez cette définition dans redux-toolkit par exemple 🙄
Les créateurs de Deno ont même décidé de ne PLUS utiliser Typescript dans leur codebase interne car cela devenait trop complexe de maintenir les types.
C'est vrai que Redux n'est pas forcément nécessaire pour démarrer une app React, tout comme Vuex ne l'est pas pour une app Vue.
Comme pour chaque outil, il faut se demander si l'on en a vraiment besoin et surtout si ça répond à un problème.
Chaque outil rajoute une couche de complexité cognitive supplémentaire qui ralentit et complique le développement.
Une autre lib qui propose de faire du frontend avec un virtual DOM.
Ils annoncent des performances bien plus élevées que React tout en supportant une partie de l'API comme useState, useEffect etc
Je suis toujours sceptique lorsque je vois les couches d'abstractions s'empilées côté frontend.
Un autre article qui analyse les faiblesses des Hooks de React.
Une source de bug très courante est l'oubli d'une propriété dans le tableau de dépendances avec useEffect.
Le respect de la Règle des Hooks qui force le nombre de Hooks d'un composant à toujours être le même impose des architectures de composants contre nature.
L'auteur continue son raisonnement en avançant notamment que depuis les Hooks, React peut être utilisé comme un framework alors que ce n'était pas vraiment prévu, ce qui cause pleins de problèmes d'architectures.
Un article qui va dans le sens inverse de la tendance actuelle autour de l'utilisation des Hooks dans React.
L'auteur disserte sur le non respect des principes SOLID par les Hooks et sur les problèmes de dettes technique que cela créé.
Les Hooks sont vraiment quelque chose d'étrange, ils ne respectent pas la programmation fonctionnelle, ni la programmation objet.
Ce sont juste des helpers pour écrire et lire de la donnée dans une sorte de gros objet global, l'avantage avec le système de props étant qu'on n'a pas besoin de les passer entre chaque composant.
Stripe ont migré une de leur application React de Flow vers TypeScript en utilisant un "codemod" pour faire la conversion.
Un framework fullstack avec une structure et une syntax inspirée de Ruby On Rails (particulièrement pour l'ORM).
C'est un des créateurs de Github derrière ce projet, pas étonnant que ça ressemble autant à Rails!
Ils exposent une API GraphQL, une auth générique, un ORM basé sur Prisma et utilisent React pour le frontend
Quelques astuces pour réduire la taille de son bundle frontend
Un backend temps réel exposant une API GraphQL pour une utilisation avec les React Hooks (mais pas que)
Un framework fullstack qui gère la partie backend et la partie frontend (en React).
Des idées intéressantes par rapport aux traditionnels framework MVP comme une construction autour des routes uniquement et une abstraction du serveur HTTP avec un support de Node, Express, Deno et autres en utilisant le standard de l'API fetch à la place
L'auteur parle de l'utilisation des WebComponents et autres API standard du web plutôt que des framework complexes de type React