Il existe de nombreux moteurs de jeu dans le monde : Unreal Engine, Unity Engine, Godot Engine, Cry Engine, et plus encore.

Qu'est-ce que ces moteurs de jeu ont en commun ? Personnalisation. Différents jeux ont des exigences différentes et nécessitent des fonctionnalités spécifiques pour atteindre leurs objectifs. Il est difficile de fournir toutes les fonctionnalités possibles dans un seul programme, c'est pourquoi de nombreux moteurs permettent aux développeurs de modifier le code source et de créer leurs propres fonctionnalités personnalisées. La personnalisation est un élément essentiel de ces moteurs.

Maintenant, revenons au développement frontend. React est l'un des frameworks les plus populaires dans cet espace. Mais, tout comme la modification du moteur est courante dans le développement de jeux, est-il aussi courant de modifier le code source interne de React dans le développement front-end ? Cette simple question en dit long sur ce que nous poursuivons réellement et met en évidence la différence de direction entre le développement frontend moderne et d'autres domaines.

React est un framework presque impossible à modifier. Vous êtes encouragé à utiliser React tel quel, et il n'est pas destiné aux développeurs de personnaliser son architecture interne ou son pipeline de rendu. Par conséquent, utiliser React signifie que vous devez résoudre tous vos besoins dans les limites de la structure de React. Mais le monde regorge d’exigences diverses, et toutes ne peuvent pas être résolues dans le cadre de React.

"Un déjeuner gratuit n'existe pas."
"Aucun outil ne peut tout faire."

React n'est qu'un outil de développement parmi tant d'autres, et il a ses limites.

La principale raison pour laquelle les développeurs utilisent React est la productivité. React a été créé avec la question : « Comment pouvons-nous développer des composants DOM plus efficacement dans le développement Web ? » Le DOM est au centre de l’approche de React. Tout comme la façon dont les fonctionnalités automatisées signifient généralement un manque de personnalisation, la « productivité » dont ils parlent signifie souvent « vous ne pouvez pas modifier la boucle de rendu étroitement couplée au navigateur via le DOM virtuel ».

Le premier problème majeur avec React est le DOM. Tout ne tourne pas autour du DOM, et tous les programmes ne fonctionnent pas uniquement autour de lui. Pourtant, React place le DOM au cœur de sa philosophie. La syntaxe JSX, où chaque composant renvoie quelque chose de « HTML Element Like », reflète clairement cet état d'esprit.

Le deuxième problème est le DOM virtuel. Voici comment fonctionne le DOM virtuel :

• Le DOM est intrinsèquement lent.
• Pour atténuer cela, React introduit une logique interne plus rapide.
• Cette logique crée un objet qui copie la forme de l'arborescence DOM réelle, connue sous le nom de DOM virtuel. Chaque fois que le rendu se produit, React trouve les modifications à l'aide de ce DOM virtuel et met à jour uniquement ces parties.
• Pour implémenter ce système, les mises à jour du DOM doivent toujours passer par l'élément racine du DOM.
• Le virtuel DOM fonctionne de manière transparente avec les opérations internes de React.

La question est : pourquoi HPSE adopterait-il un tel système en premier lieu ? Outre la crainte que cette approche de rendu ne puisse pas répondre aux diverses exigences HPSE, la plus grande préoccupation est son manque d'utilité réelle dans ce contexte.

Dans HPSE, les composants DOM peuvent être gérés au niveau de la classe. Lorsqu'une instance est créée, sa référence DOM div de niveau supérieur est stockée en tant que variable membre. Les méthodes privées de l'instance peuvent soit manipuler directement la référence DOM, soit utiliser querySelector() pour y accéder. Dans la plupart des cas, cela serait plus rapide que de comparer l'intégralité de l'arborescence DOM.

L'utilisation du DOM virtuel n'est qu'un moyen d'identifier les modifications, mais si les modifications sont déjà stockées en interne dans votre instance, les rechercher à nouveau est redondant. Une fois l'élément DOM mis à jour, le navigateur déclenchera toujours ReFlow et RePaint, il n'y aura donc aucune différence de performances par la suite.

Le problème ultime réside dans les « opérations internes » de React. Quelles sont exactement ces opérations internes ? Il y a un manque de documentation ou d'informations détaillées, et la plupart des développeurs frontend ne les comprennent pas non plus. Le client du navigateur fonctionne déjà au sein de la couche d'abstraction du navigateur lui-même, ce qui le rend vulnérable à divers défis. Les processus internes opaques et non modifiables de React ne font qu’exacerber cette vulnérabilité.

Les modifications apportées aux composants dans React doivent passer par le DOM virtuel, et le DOM virtuel est géré par l'architecture Fibre, qui suit des règles de priorité spécifiques. Cependant, il existe peu de documentation sur la façon de personnaliser les fonctions internes de React pour répondre aux exigences de performances en temps réel ou de synchronisation de précision de HPSE. C'est comme développer un jeu AAA avec un moteur qui ne peut pas être personnalisé.

"Pourquoi s'embêter ?"

C'est une question qui revient sans cesse.

React est si étroitement couplé en interne que même si vous vouliez le modifier, vous ne pourriez pas. Il n’a jamais été conçu dans ce but. De plus, le fort couplage entre le rendu et les mises à jour d'état rend React inadapté aux projets HPSE, où les composants non visuels comme les données ou les éléments 3D doivent être gérés aux côtés des éléments DOM.

Dans HPSE, le timing des appels d'événements et des démontages de mémoire peut ne pas être lié à des composants individuels, mais React applique cette structure basée sur les composants, ce qui rend difficile la gestion de telles exigences. La conception de React, dans laquelle les changements d'état des composants peuvent affecter l'ensemble de l'arbre de rendu, entre également en conflit avec la nécessité de HPSE de minimiser ou de contrôler ces impacts.

Des bibliothèques comme React Three Fiber (R3F) vous permettent de créer des instances comme Mesh ou Scene en utilisant une syntaxe "HTML Element Like", mais c'est simplement Three.js adapté à la structure de React. Le niveau élevé de couplage au sein de React ne fait qu'aggraver le problème des composants internes non modifiables.

L'approche de gestion des événements de React est également problématique. React utilise un système d'événements synthétiques pour garantir la compatibilité du navigateur et la cohérence dans la gestion des événements. Cependant, en ajoutant une couche d'abstraction au traitement des événements, ce système limite le contrôle précis des boucles d'événements et du timing nécessaire dans HPSE, ce qui rend difficile la mise en œuvre des optimisations essentielles.

Ces problèmes surviennent parce que la philosophie de conception de React est fondamentalement différente des objectifs de HPSE. React n'a pas été conçu pour HPSE ; il a été conçu pour optimiser le développement de clients Web standards. Si React avait suivi une direction similaire à HPSE, ses fonctionnalités auraient été très différentes et il serait justifié de l'adopter dans le développement HPSE. Mais comme leurs objectifs sont si divergents, ils se séparent inévitablement.

Cela ne veut pas dire que tout dans React, comme le routage ou useEffect, est mauvais. En fait, la plupart de ces fonctionnalités peuvent être implémentées à l’aide de modules ou de codes JavaScript autonomes. Contrairement à React, les modules JavaScript généraux n'appliquent pas de pipelines ou de règles spécifiques aux projets. De plus, s'ils sont open source, vous pouvez modifier leurs composants internes en fonction de vos besoins.