Structurer le code de ses applications

Introduction

Un autre point sur lequel React n’échappe pas aux principes généraux de la programmation, c’est que la programmation informatique est aussi une activité sociale, en ce sens que, très souvent, un développeur est amené à travailler au sein d’équipes de développement. Chaque entreprise, voire chaque équipe de développeurs au sein d’une entreprise, va développer ses propres processus de développement, ses propres normes, etc. Mais il existe des principes plus généraux qui permettent d’organiser son code de la meilleure manière possible. Ce qui est requis ici, c’est davantage un certain sens de l’organisation et de l’architecture que de réelles compétences logiques. Il ne s’agit pas simplement d’écrire du code, mais d’écrire du code de qualité.

En effet, écrire du code informatique est en réalité à la portée de tout le monde, mais quelqu’un qui écrit du code informatique n’est pas nécessairement un bon développeur. Le code produit doit être maintenable dans le temps et ne pas devenir du spaghetti code, c’est-à-dire un entassement de lignes de code qu’aucun développeur (y compris l’auteur du code en question) ne sera capable de modifier...

Les design patterns en React

1. Les composants d’ordre supérieur (HOC)

Les HOC (Higher Order Components ou composants d’ordre supérieur en français) sont des composants qui centralisent les parties redondantes l’application ayant pour visée d’être réutilisées à plusieurs endroits dans le code. Les HOC injectent des éléments d’UI et/ou de logique métier dans un composant pour enrichir son fonctionnement.

Imaginons un site avec plusieurs pages, dont plusieurs d’entre elles seraient réservées aux utilisateurs authentifiés. Il est probable que l’on se retrouve avec une logique dupliquée entre plusieurs pages : pour chacune de ces pages, il faudra un bout de logique (interroger l’application pour savoir si l’utilisateur est connecté) et un bout d’affichage ou une redirection (si l’utilisateur n’est pas connecté). C’est pour éviter ces redondances qu’entrent en scène les HOC.

Souvent, les HOC sont comparés à l’héritage en programmation orienté objet. Toutefois, React est désormais tourné vers le paradigme fonctionnel. Le terme plus adéquat est celui de « composition ». L’héritage implique des possibilités telles que le polymorphisme ou l’héritage des attributs ou des méthodes que ne permettent pas les HOC qui ne font qu’injecter une fonctionnalité dans un composant.

Les HOC sont des fonctions qui prennent en paramètre un composant, lui appliquent une certaine logique, et le retournent enrichi de cette fonctionnalité. Pour ce faire, cette fonction va elle-même retourner une fonction qui prend en paramètre les propriétés du composant, et qui va retourner ce même composant enrichi. Par convention, leur nom commence toujours par le mot with.

Dans le cas qui nous intéresse, nous pouvons créer un fichier with-authentication.tsx, ainsi qu’une fonction withAuthentication. Cette fonction, comme nous l’avons dit, prend en paramètre un composant de type ComponentType<T>. Un HOC est une fonction qui, par principe, peut prendre n’importe quel type de composant… D’où la nécessité de la généricité....

Les principes SOLID en React

Les principes SOLID sont des principes traditionnellement utilisés dans le domaine de la programmation orientée objet (POO) pour produire un code plus flexible, plus robuste, et plus facile à maintenir. Il n’est pas question, avec ces principes, de concepts fondamentaux de la programmation : un développeur peut parfaitement construire des applications qui fonctionnent sans tenir compte de ces principes. Toutefois, il est très probable que la maintenance de ces applications soit beaucoup plus difficile. Malgré leur origine très liée à la POO, ces concepts s’appliquent parfaitement au développement de composants en React.

Lorsque ces principes sont correctement appliqués en React, le code est davantage découplé, modulaire, et s’adapte mieux aux éventuels changements dans le code de l’application. Ils incitent à penser l’architecture de l’application non pas comme une hiérarchie de composants rigide, mais comme un réseau de composants flexibles et autonomes qui communiquent via des interfaces claires et bien définies.

1. Le S comme Single responsibility

Le principe de responsabilité unique (single responsibility principle) est au fondement d’une architecture et d’un développement de composants sains. Chaque composant ne devrait, selon ce principe, n’avoir qu’une seule responsabilité. En React, cela se traduit par le fait qu’un composant ne devrait pas gérer des éléments d’affichage ou des états qui sont hors de sa portée. Par exemple, un composant Button qui gérerait en interne l’envoi de données vers une API externe serait un très mauvais composant. Il est préférable de séparer les deux responsabilités dans deux composants distincts.

Adopter ce principe permet tout d’abord de rendre les bugs plus faciles à ségréguer. Un composant ayant des responsabilités mal définies, lorsqu’il est modifié et qu’un bug est introduit, est plus difficile à déboguer. À l’inverse, lorsque le composant est implémenté sous le principe de responsabilité unique, il est plus simple à lire et il est plus facile de lui trouver...

L’architecture des composants

1. La clean architecture en React

Les principes de clean architecture sont un ensemble de principes de conception logicielle visant à organiser le code afin qu’il soit indépendant de dépendances externes (frameworks, bases de données, etc.). Cette sous-section sera plus théorique et peut être lu comme une somme de principes ayant sous-tendu les choix de rédaction des parties précédentes.

Ces principes ont été théorisés par Robert C. Martin en 2012. Ils ne sont pas spécifiques à React et peuvent être utilisés pour toute sorte de projet, language, framework, etc. L’idée principale est de diviser le code de l’application en cercles concentriques dans lesquels le flux des dépendances ne peut aller que de l’intérieur vers l’extérieur. Le cœur du système (les règles métiers, les définitions de types, etc.) est au centre (et ne devrait donc n’utiliser aucune dépendance externe), et les détails d’implémentation (UI, communication avec des API, etc.) sont à la périphérie et peuvent donc dépendre des abstractions qui constituent le cœur du système. On peut diviser ces principes en quatre couches principales.

La première couche est celle des entités (le core domain ou domaine central). Il s’agit des modèles de données fondamentaux de l’application. Il peut s’agir d’objets simples, d’interfaces et de types qui définissent les données utilisées par l’application. Ces types ne doivent pas avoir connaissance des détails d’implémentation (et la très grande...