Les indispensables d’un projet frontend - Séparer les responsabilités entre Composants Intelligents et Composants de Présentation

Voici plusieurs années que je travaille sur des projets informatiques en tant que développeur fullstack spécialisé dans le domaine du frontend. Je vous propose dans cette série d’articles de découvrir les bonnes pratiques qui facilitent la vie au quotidien des équipes.

Nota Bene : Cet article est rédigé pour des architectures frontend avec une approche composant.

Le problème

Au fil des projets Front, les composants deviennent de plus en plus complexes. Les passages de props (ou via des Inputs Angular) deviennent nombreux. Certains composants n’utilisent pas les props qu’ils reçoivent mais se contentent de transférer ces données à leur enfant(s).

Un peu de théorie

Dan Abramov, co-auteur de Redux et de Create React App, sépare dans cet article les composants en deux grands types :

https://medium.com/@dan_abramov/smart-and-dumb-components-7ca2f9a7c7d0

Les composants de présentation :

• dont la responsabilité est d’afficher la donnée.
• comportent des éléments de DOM et leur propre style.
• ne comportent aucune dépendance externe.
• ne se soucient pas du chargement, ni de la modification des données.
• récupèrent de la donnée uniquement via des props (ou Inputs).
• ont rarement un état interne (s’ils en ont un, c’est un état pour l’interface, pas pour la donnée).

Les composants intelligents (ou composants conteneurs) :

• dont la responsabilité est de gérer la logique frontend, c’est-à-dire toute la logique qui découle des règles de l’interface client.
• comportent peu d’éléments de DOM et pas de styles.
• fournissent les données et le comportement aux autres composants.
• peuvent être connectés au store
• possèdent un état interne (un state) et sont utilisés comme maître de la donnée.

La solution

Introduire progressivement une séparation entre des composants spécialisés pour réaliser de la présentation de données et d’autres composants plus intelligents pour préparer les informations pour la vue.

Quand introduire une séparation entre composants de présentation et composants intelligents ?

Je recommande de commencer par construire des composants de présentation. Néanmoins, lorsque la logique devient complexe, lorsque l’affichage dépend de multiples états et que de nombreux composants ne servent qu’à échanger des props, alors il est temps d’utiliser des composants intelligents.

Mise en place

C’est un processus de refactoring continuel, qui nous permet de déterminer quels sont les bons éléments à extraire. Il est compliqué d’y parvenir dès le premier essai. Au fil de nos expériences avec le pattern, une espèce d’intuition permet de savoir quand extraire les composants intelligents. En résumé, dès qu’il y a, au sein du même composant, des règles de présentation et un état interne du composant, alors il faut séparer les composants en deux.

Avantages

• Meilleure séparation des responsabilités.
• Meilleure réutilisabilité des composants de présentation potentiellement mis à disposition de plusieurs composants intelligents.
• Il est possible de se constituer une palette de composants de présentation de l’application. En créant des storys chez Storybook avec ces composants, l’intégrateur peut tester ses idées sans être dépendant de la logique de l’application.
• Les composants de mise en page (NavBar, Button, Page) sont extraits et ne sont plus dupliqués à plusieurs endroits du code.

Inconvénients

• Plus d’abstraction dans les composants.
• Difficultés à connaître quand il est nécessaire de découper un composant.
• Plus de fichiers dans la codebase.

Retrouvez les articles de cette série ici :

Un Backend For Frontend, une API sur-mesure

Limiter la logique dans les composants