React est un excellent outil pour mettre en œuvre des sites web interactifs simples. Mais dans quelle mesure est-il applicable aux projets frontaux complexes ? Est-ce que ça marche aussi bien dans ce contexte ?

Dans cet article, nous allons examiner certains des problèmes que vous pouvez rencontrer lors de l'utilisation de React pendant le développement web. Vous apprendrez également pourquoi l'auteur de l'article a décidé de développer un nouveau framework sur Scala, grâce auquel il a réussi à réduire le nombre de lignes de code de 30 mille (sur React) à mille.

Points clés

- Les composants React sont difficiles à réutiliser dans des projets web complexes.
- L'algorithme du DOM virtuel de React est lent et imprécis.
- Les modèles HTML de React ne sont ni complets ni puissants.
- React nécessite une programmation asynchrone complexe lors de la communication avec le serveur.

Binding.scala contient moins de concepts mais plus de fonctionnalités. Prospective Binding.scala résout des problèmes complexes que React ne peut pas résoudre.

Conditions préalables

Pour beaucoup, le framework React semble plus simple et plus convivial qu'AngularJS. L'une de ses fonctions les plus utiles est la liaison de données. Il vous permet d'associer des sources de données à des éléments de pages Web, ce qui constitue un moyen pratique de mettre en œuvre des sites Web interactifs simples.

Cependant, il peut y avoir des situations où React ne peut pas résoudre des problèmes confus aussi facilement que des problèmes simples. Si vous expérimentez TodoMVC, vous constaterez qu'une application dans le cadre Binding.scala ne contient que 154 lignes de code, contre 488 lignes dans React.

Problème 1 : les composants React sont difficiles à réutiliser dans des projets Web interactifs complexes.

L'unité minimale de réutilisation dans React est le composant (React.Component). Il est plus léger que le contrôleur et la vue dans AngularJS. Tout ce qu'un développeur web doit faire, c'est mettre en œuvre une fonction de rendu qui traduit les propriétés (props) et l'état du composant en éléments HTML.

Ce composant léger est très utile pour créer des pages Web simples. Toutefois, lorsque la communication entre les composants est nécessaire, le passage de fonctions de rappel est inévitable. En particulier pour les pages Web aux structures complexes, des dizaines de composants interdépendants doivent être utilisés, où les rappels sont transmis de parent à enfant, de couche en couche. La seule conséquence de la mise en œuvre des frameworks React dans ce type de projets web complexes et interactifs est que le code deviendra trop encombré et difficile à maintenir.

Problème 2 : Le DOM virtuel dans React est lent et imprécis.

L'algorithme de rendu dans React utilise le DOM virtuel.

Le développeur doit fournir une fonction de rendu qui crée un DOM virtuel en utilisant les propriétés et l'état du composant. Et React construit le DOM réel sur la base de ce DOM virtuel.

Lorsque l'état change, React appelle à nouveau la fonction de rendu et construit un nouveau DOM virtuel. Il analyse ensuite les différences entre l'ancienne et la nouvelle version du DOM virtuel et les applique au DOM réel.

Ce procédé présente deux inconvénients :

1. Indépendamment de ce qui a changé dans l'état, les fonctions de rendu génèrent toujours un nouveau DOM virtuel complet. Si la fonction de rendu est complexe, les ressources informatiques sont gaspillées.
2. La comparaison de deux versions du DOM est lente et source d'erreurs. Par exemple, si vous voulez insérer un élément li au début de ul, React supposera à tort que vous avez modifié tous les composants li dans ul et ajouté un li à la fin.

Comme les deux versions du DOM virtuel sont indépendantes l'une de l'autre, React n'a aucune idée de ce qui se passe réellement. Il devine aléatoirement les changements qui se sont produits en se basant sur les deux DOMs. Cet algorithme est très lent et imprécis. Les développeurs Web sont obligés d'utiliser la propriété key, ainsi que les méthodes shouldComponentUpdate et componentWillUpdate, pour aider le framework à deviner correctement. 

Problème 3 : les modèles HTML React ne sont ni complets ni puissants

React prend en charge JSX pour le développement de modèles HTML.

En théorie, les développeurs frontaux peuvent transformer du HTML statique en une page web dynamique en copiant simplement le HTML dans des fichiers JSX et en ajoutant un peu de code supplémentaire. En effet, React est plus adapté à la réutilisation de modèles HTML que d'autres frameworks tels que Cycle.js, Widok et ScalaTags.

Malheureusement, le support HTML de React est incomplet. Le développeur doit remplacer manuellement class par classname et for par htmlFor. En outre, la syntaxe des styles en ligne doit passer de CSS à JSON. Et si les développeurs web peuvent copier du HTML dans du code, cela demande encore beaucoup de temps et d'efforts. On ne peut donc pas dire que React est supérieur à Cycle.js, Widok ou ScalaTags.

React fournit un mécanisme propTypes pour vérifier la validité des données. Mais ce mécanisme est plein de trous. Même en utilisant propType, React ne peut trouver les erreurs qu'au moment de l'exécution, et non au moment de la compilation.

React est également incapable de trouver les erreurs dans les noms. Par exemple, si vous écrivez onclick au lieu de onClick, il n'y aura pas de message d'erreur, mais le programme se plantera. Les développeurs consacrent généralement beaucoup de temps et d'énergie à la recherche de ces erreurs absurdes.

Problème 4 : React nécessite une programmation asynchrone complexe lors de la communication avec le serveur.

Considérez le travail de React avec le serveur en termes de schéma Modèle-Vue-Vue-Modèle. Un développeur web doit mettre en œuvre une couche d'accès à la base de données (Model), un état en tant que ViewModel et une fonction de rendu en tant que View. Le modèle donne accès à l'API dorsale et définit l'état (ViewModel) à l'aide de promesses (Promise and fetch API). Ensuite, render (View) assure le rendu du ViewModel sur les pages web.

Au cours de ce processus, les programmeurs frontaux doivent développer une procédure asynchrone composée d'un tableau de fermetures. Le code d'une telle procédure devient inévitablement confus et source d'erreurs. Même si vous faites très attention à garder la trace de toutes sortes d'événements asynchrones, le processus de débogage et de maintenance d'un tel programme devient extrêmement difficile.

Conclusions

Binding.scala semble similaire à React à certains égards. Mais le mécanisme sous-jacent est complètement différent de React et Widok, il est plus simple et plus polyvalent. Binding.scala est plus flexible et plus puissant que React. Nous pouvons utiliser Binding.scala pour résoudre des problèmes complexes que React ne peut pas résoudre.

En plus des quatre aspects mentionnés ci-dessus, il y a également un problème assez important de gestion de l'état dans React. Si nous utilisons une bibliothèque tierce comme Redux pour gérer l'état, la structure de l'application devient encore plus confuse et le nombre de couches augmente.

En comparaison, Binding.scala décrit un état complexe en utilisant le même mécanisme de liaison de données que pour le rendu des pages Web. Et il n'est pas nécessaire de recourir à des bibliothèques tierces pour fournir des fonctionnalités telles que la communication client-serveur, la gestion de l'état et la répartition des URL.