Meta publie React Compiler, un compilateur open source pour React, afin d'optimiser le code pour la performance

Meta a déjà utilisé le compilateur depuis plus d'un an

Meta a publié React Compiler, un compilateur open source pour React lors de la React Conference, qui s'est tenue à Las Vegas et a été retransmise en direct. Joe Savona, membre de l'équipe React de Meta et ingénieur en interface utilisateur, a déclaré que l'équipe avait développé le compilateur au cours des dernières années.

React est une bibliothèque JavaScript frontale gratuite et open-source pour la construction d'interfaces utilisateur basées sur des composants. Elle est maintenue par Meta (anciennement Facebook) et une communauté de développeurs individuels et d'entreprises.

« React Compiler optimise automatiquement vos composants et hooks, de sorte que seules les parties minimales de votre interface utilisateur se mettent à jour en fonction des changements d'état », a expliqué M. Savona au public présent lors de la React Conference 2024. « Cela semble donc assez magique ».


Objectifs de React Compiler

L'idée de React Compiler est de permettre aux développeurs d'utiliser le modèle de programmation déclaratif familier de React, basé sur les composants, tout en garantissant que les apps sont rapides par défaut. Concrètement, les objectifs à atteindre sont les suivants :

• Limiter la quantité de re-rendu lors des mises à jour afin de garantir des performances rapides et prévisibles par défaut pour les applications.
• Maintenir un temps de démarrage neutre par rapport aux performances antérieures à l'utilisation du compilateur React. Cela signifie notamment que l'augmentation de la taille du code et les frais généraux de mémorisation doivent être suffisamment bas pour ne pas avoir d'impact sur le démarrage.
• Conserver le modèle de programmation déclaratif et orienté composant de React. En d'autres termes, la solution ne devrait pas changer fondamentalement la façon dont les développeurs pensent à écrire React, et devrait généralement supprimer des concepts (le besoin d'utiliser React.memo(), useMemo(), et useCallback()) plutôt que d'en introduire de nouveaux.
• Travailler sur du code React idiomatique qui suit les règles de React (fonctions de rendu pures, règles de hooks, etc.).
• Prendre en charge les outils et flux de travail typiques de débogage et de profilage.
• Être suffisamment prévisible et compréhensible par les développeurs React - c'est-à-dire que les développeurs devraient être en mesure de développer rapidement une intuition approximative de la façon dont React Compiler fonctionne.
• Ne pas nécessiter d'annotations explicites (types ou autres) pour le code produit typique. Des fonctionnalités permettant aux développeurs d'utiliser les informations de type pour permettre des optimisations supplémentaires peuvent être proposées, mais le compilateur doit fonctionner correctement sans informations de type ou autres annotations.
  

Non-objectifs

Les éléments suivants ne sont explicitement pas des objectifs pour React Compiler :

[LIST][*] Fournir un re-rendu parfaitement optimal sans aucun recalcul inutile. Il s'agit d'un non-objectif pour plusieurs raisons :

• Le surcoût d'exécution lié au suivi supplémentaire peut l'emporter sur le coût du recalcul dans de nombreux cas.
• Dans les cas de dépendances conditionnelles, il peut être impossible d'éviter de recalculer certaines ou toutes les instructions.
• La quantité de code peut faire régresser les temps de démarrage, ce qui irait à l'encontre de l'objectif de neutralité des performances de démarrage.
  

[*] Soutenir le code qui viole les règles de React. Les règles de React existent pour aider les développeurs à construire des applications robustes et évolutives et forment un contrat qui permet de continuer à améliorer React sans casser les applications. React Compiler dépend de ces règles pour transformer le code en toute sécurité, et les violations des règles briseront donc les optimisations de React Compiler.[*] Prendre en charge les anciennes fonctionnalités de React. Notamment, les composants de classe ne seront pas pris en charge en raison de leur état mutable inhérent partagé entre plusieurs méthodes avec des durées de vie et des flux de données complexes.[*] Prendre en charge 100 % du langage JavaScript. En particulier, les fonctionnalités rarement utilisées et/ou celles qui sont connues pour être dangereuses ou qui ne peuvent pas être modélisées correctement ne seront pas prises en charge. Par exemple, les classes imbriquées qui capturent des valeurs à partir de leur fermeture sont difficiles à...