Adopter une approche par composant

Introduction à la programmation par composant

« D’abord réunir sous une seule idée générale toutes les idées particulières, afin de bien faire comprendre, par une définition précise, le sujet que l’on veut traiter. […] Puis décomposer à nouveau une idée selon ses articulations naturelles, tâchant de ne point mutiler chaque partie comme le ferait un mauvais dépeceur. » - Platon, Phèdre, ~370 av. J.-C.¹

C’est sur cette citation que Chistopher Alexander, jeune professeur d’architecture de l’UC Berkeley, ouvre en 1964 son deuxième ouvrage, Notes on the Synthesis of Form². Ce livre deviendra rapidement un incontournable pour tout chercheur en informatique, les processus de conception génériques qu’il contient s’appliquant parfaitement à ce domaine.

Il est ainsi cité à de nombreuses reprises au cours des années 1960 et 1970, et notamment durant la conférence d’octobre 1968 du conseil scientifique de l’OTAN sur le génie logiciel³. Sa lecture a certainement grandement influencé Douglas McIlroy qui présente durant cette même conférence ce qui est généralement reconnu comme le discours fondateur de la programmation orientée composant (ou POC) : Mass produced software components.

Nous ayant menés de la dialectique platonicienne aux architectures distribuées modernes, en passant par la philosophie d’Unix et la programmation orientée objet, l’idée même de "composant" est bien trop ancienne, et bien trop vaste, pour être détaillée ici.

Nous allons donc dans cette section simplement et succinctement explorer les modes de pensée que la programmation orientée composant implique, afin de mieux nous préparer à l’exploration de ses applications concrètes au développement web.

1. Un cadre de référence nécessaire

Tout analyste confronté à un projet d’envergure, quel que soit son domaine, doit s’assurer à la fois de l’efficacité de sa mise en œuvre (productivité) et de sa stabilité sur le long terme (durabilité/maintenabilité).

Cependant, un projet conséquent...

Premières fondations pour le Web

Avant toute chose, les composants se doivent d’être réutilisables. En ce sens, un mécanisme commun est nécessaire, afin de permettre leur emploi sur une même plateforme et d’exposer des interfaces pour manipuler et interroger leurs états.

Pour la représentation graphique sur le Web, ce mécanisme repose sur le langage HTML et le DOM. Or, ces standards sont forcément limités, couvrant les usages les plus communs et génériques via un ensemble fini d’éléments. Créer un composant web repose donc toujours sur une même logique, quelle que soit la solution employée : étendre HTML, c’est-à-dire permettre au développeur de définir, d’une manière ou d’une autre, ses propres éléments/balises.

Initialement, aucun navigateur ne permettait cependant d’effectuer cette opération. Ce manque a été comblé par l’emploi de bibliothèques.

1. Plug-ins

jQuery est né en 2006, donc assez récemment et est encore omniprésent. Selon les chiffres du W3Techs, cette bibliothèque est utilisée en novembre 2020, par 77 % des 10 millions de sites web les plus fréquentés, tandis qu’Angular, React et Vue.js sont tous trois en dessous des 0,5 %⁸. Ces chiffres ne sont pas représentatifs de l’usage de ces bibliothèques pour le développement d’applications web modernes. Malgré les quelques améliorations apportées au fil des années, jQuery demeure en effet difficilement envisageable pour de tels projets, du fait de son poids (30 Ko après minification et compression) comme de ses performances, au regard de la simplicité de ses fonctionnalités. Depuis plusieurs années, son abandon est généralement souhaité, voire applaudi, comme cela a été le cas pour GitHub, en septembre 2018⁹, ou encore Bootstrap 5, en juin 2020¹⁰.

À la fin des années 2000, jQuery était omniprésent et constituait ainsi un quasi-standard de fait. La plupart des premiers composants graphiques réutilisables ont donc été créés spécifiquement pour cette bibliothèque.

jQuery...

Liens avec une approche fonctionnelle

Quand il s’agit d’évoquer une approche fonctionnelle du développement web, React, qui a grandement contribué à la populariser, est toujours la première solution évoquée.

Sans entrer dans les détails de cette bibliothèque (ce qui nécessiterait un ouvrage à part entière), nous allons nous appuyer sur son exemple pour étudier les "composants fonction", et leur utilité dans un cadre plus général.

1. Fonctions et réactivité

Depuis ses premiers jours, React est systématiquement associé à la programmation fonctionnelle. Pourtant, le développement web en général est difficilement conciliable avec les principes stricts d’un tel paradigme. Et de fait, React n’est pas, à proprement parler, "fonctionnel".

Basiquement, la programmation fonctionnelle pourrait en effet être définie comme un modèle visant au découpage d’un programme en fonctions simples, comme la POO le ferait via des objets et classes. Or, React conceptualise précisément le Web comme une projection de données brutes en code HTML, prenant la forme d’un "flux unidirectionnel de données" (one-way data flow) passant par une composition de fonctions. Pour ce faire, l’accent est mis au maximum sur l’utilisation de modèles de données immuables, et l’utilisation de fonctions pures²³.

Flux unidirectionnel de données React

Le principe de composition est loin d’être spécifique au développement web, ni même à la programmation. De manière générale, nous pouvons faire remonter sa définition la plus générale aux mathématiques, et au procédé de la composition de fonctions.

Le concept est très simple : à partir de deux fonctions opérant sur les mêmes ensembles, il est possible d’en constituer une troisième en les "imbriquant". Par exemple, avec les fonctions f: x -> 2x et g: x -> x + 3, nous obtenons la fonction composée g o f (ou g(f(x))) x -> 2x + 3.

Nous allons cependant rapidement voir que cette "philosophie", appliquée au développement web, nécessite...

Naissance d’un standard

Après ses débuts en tant que réseau documentaire (et après la première tentative de formalisation de HTML en 1993), le Web devient très rapidement une plateforme de développement applicatif, grâce à l’invention de JavaScript par Netscape en 1994 (voir le chapitre Comprendre l’histoire du Web et de ses standards). Les applications ne cessant de se complexifier, peu de temps passe avant que les premiers travaux de définition d’un mécanisme commun de composantisation soient lancés.

’’Composantisation’’, anglicisme directement dérivé de "componentization", désigne un processus de division en composants. De manière générale, le terme ’’modularisation’’ est privilégié afin d’éviter le calque linguistique. Nous utiliserons cependant "composantisation’’ ici, afin d’éviter toute ambiguïté entre composants et modules, ces derniers étant généralement associés à un découpage de niveau supérieur (par exemple, dans le cas des modules Angular). "Modularisation" sera par ailleurs utilisé comme un terme générique.

1. Les prédécesseurs

L’année 1998 a en particulier connu (via le W3C) deux grandes initiatives visant à définir un tel mécanisme (celui de composantisation), avec la publication, en octobre, de la note "Componentizing Web Applications",³⁷ première et unique tentative de standardiser les HTML components (HTC), suivie de près par le premier WD XHTML (intitulé "Reformulating HTML in XML"³⁸).

XHTML a en partie été un effort constant pour permettre une plus grande modularité. L’extension de sa syntaxe par l’ajout de nouveaux espaces de noms (xmlns) permet ainsi à de nombreux outils tiers de proposer leurs propres mécanismes de composantisation.

JSF (Java Server Faces) proposera ainsi les composite components, séparant clairement l’interface du composant de son implémentation via deux balises dédiées.

<html 
 xmlns="http://www.w3.org/1999/xhtml" 
 xmlns:h="http://java.sun.com/jsf/html" ...

Références

1. PLATON. Phèdre [En ligne]. [s.l.] : [s.n.], [s.d.]. Disponible sur : https://www.atramenta.net/lire/oeuvre42287-chapitre-1.html (consulté le 20 novembre 2020).

2. ALEXANDER C. Notes on the Synthesis of Form. 7^e éd. [s.l.] : Harvard University Press, 1973. ISBN : 978-0-674-62751-2.

3. MCCLURE R. M. « NATO Software Engineering Conference 1968 ». [s.l.] : [s.n.], 1968. p. 136. Disponible sur : http://homepages.cs.ncl.ac.uk/brian.randell/NATO/nato1968.PDF.

4. DORTIER J.-F. « La perception, une lecture du monde ». Sciences Humaines [En ligne]. Juin 2007. Vol. Grands Dossiers, n° 7,. Disponible sur : https://www.scienceshumaines.com/la-perception-une-lecture-du-monde_fr_21020.html (consulté le 14 novembre 2020).

5. HAMLIN D. A., ÉD. MIL-C-44072C : COOKIES, OATMEAL ; AND BROWNIES; COCOLATE COVERED [En ligne]. 30 avril 1990. Disponible sur : http://liw.iki.fi/liw/misc/MIL-C-44072C.pdf (consulté le 12 novembre 2020).

6. « Prototypes Objet ». In : Documentation du Web - MDN [En ligne]. [s.l.] : [s.n.], [s.d.]. Disponible sur : https://developer.mozilla.org/fr/docs/Learn/JavaScript/Objects/Prototypes_Objet (consulté le 12 novembre 2020).

7. « Classes ». In : Documentation du Web - MDN [En ligne]. [s.l.] : [s.n.], [s.d.]. Disponible sur : https://developer.mozilla.org/fr/docs/Web/JavaScript/Reference/Classes (consulté le 12 novembre 2020).

8. « Usage Statistics and Market Share of JavaScript Libraries for Websites ». In : W3Techs [En ligne]. [s.l.] : [s.n.], [s.d.]. Disponible sur : https://w3techs.com/technologies/overview/javascript_library (consulté le 16 novembre 2020).

9. GITHUB ENGINEERING. Removing jQuery from GitHub.com frontend [En ligne]. The GitHub Blog. 6 septembre 2018. Disponible sur : https://github.blog/2018-09-06-removing-jquery-from-github-frontend/ (consulté le 15 novembre 2020).

10. OTTO M. Bootstrap 5 alpha! [En ligne]. Bootstrap Blog. 16 juin 2020. Disponible sur : https://blog.getbootstrap.com/2020/06/16/bootstrap-5-alpha/ (consulté le 15 novembre 2020).

11. jQuery: src/jquery.js (entry point) [En ligne]. [s.l.] : [s.n.], [s.d.]. Disponible sur : https://github.com/jquery/jquery/blob/master/src/jquery.js (consulté le 15 novembre 2020).

12. « <input> »....