Bonnes pratiques des "components" (Vue, Flutter, ...)

Bonsoir !

Je me pose une question depuis maintenant plusieurs semaines, mais je ne parviens pas à trouver de réponse vraiment claire. Je tente alors ma chance ici.

Aujourd’hui, il existe de nombreux framework qui sont pensés "composants". Pour prendre l’exemple que je connais le plus, VueJS, on peut créer nos propres composants.

Par exemple, si je créer une application qui permet de gérer ses comptes, et qu’elle n’a qu’une fonctionnalité : Je peux ajouter une dépenses, et je peux voir ma liste des dépenses.

Ici, avec Vue, on aurait disons 3 composants :

• Le composant "Formulaire" qui permet d’ajouter une dépense
• Le composant "Liste des dépenses" qui permet d’afficher la liste des dépenses
• La "page" qui inclus ces deux composants. Pour celui-ci, a voir si c’est vraiment considérer comme un composant, mais disons que oui.

Je prend l’exemple avec VueJS, mais je crois que le principe est le même pour Flutter et React (pour ce dernier, je ne suis vraiment pas sûr).

Je me pose alors la question des "bonnes pratiques".

En effet, notre composant "Liste des dépenses" peut être concus de deux manières :

• Soit c’est à l’intérieur même de ce composant que l’on récupère les données (donc ici, la liste des dépenses) et qu’on les affichent
• Soit on ne récupère aucune données dans ce composants, il ne fait que prendre en paramètre les données et les afficher.

Dans le premier cas, le composant pourra être réutilisé très simplement. On l’inclus où on veut afficher la liste des dépenses et tout fonctionne. En revanche, on ne pourra afficher qu’une seule et même liste.

Dans le second cas, c’est plus difficile d’utiliser ce composant, car avant de l’inclure, on devra au préalable récupérer la liste des dépenses pour pouvoir les passer en paramètre au composant. L’avantage en revanche, c’est que ce composant ne se chargera que de l’affichage des données, et on pourra donc le réutiliser pour d’autres données qui devront se présenter de la même façon.

Les deux façon ayants leurs avantages et inconvénient, je ne parviens pas à savoir laquelle il faut choisir. Existe-t-il une "bonne pratique" à ce sujet ? Des recommandations quelconques ? Ou alors on fait comme on veut ?

Merci !

Bonjour FougereBle, la deuxième solution est le plus proche du fonctionnement des composants. Justement tu inclus en paramètre ta liste, ce qui permet ensuite avec des tests unitaires de s’assurer (avant un commit ou manuellement après une modif) de vérifier que ton composant fonctionne toujours bien de la même manière. Je te conseille de regarder l’Atomic Design, ça te donnera une idée : https://www.usabilis.com/atomic-design/

Merci pour ta réponse !

Ca me paraît pas logique tout ça.

Pour moi, un composant doit être autonome. Il doit pouvoir être détaché et rester fonctionnel, sans dépendre d’autres choses. En passant les données en paramètres :

• Le composant n’est plus parfaitement autonome
• Il n’est plus vraiment fonctionnel seul
• C’est comme si on découpais le composant en deux (le composant pour l’affichage, plus le composant parent pour les données)
• C’est moins clair : Si j’ai 5 composants qui demandent des données dans ma page, je vais devoir dans cette page faire mes requêtes, ce qui alourdi le code de la page

Ce n’est pas logique pour moi non plus qu’une liste, on doit la passer en paramètres, alors qu’on ne passe qu’un ID quand c’est un seul item que l’on veut afficher (par exemple : Détail d’une dépense - on ne passe que l’ID de la dépense, et c’est le composant qui va chercher les données).

En revanche, je comprend bien l’intérêt de passer les données : Le composant est réutilisable (ce qui est quand même aussi le but d’un composant) et on peut effectivement tester le composant (important aussi).

Ok, je comprend mieux.

Donc si je résume, au niveau des composants, on à en fait deux types si je comprend bien :

• Les composants "génériques" qui ne font que de l’affichage et peuvent être réutilisé pour plusieurs choses (et à plusieurs endroits).
• Les composants "fonctionnels" qui sont autonomes. Par exemple, un formulaire de connexion : C’est le composant "Connexion" qui se charge d’afficher le formulaire (peut être en utilisant des composants génériques) et de connecter l’utilisateur (donc la partie "Fonctionnel").

Ainsi, dans l’exemple que j’ai donné dans le premier message, le composant "Liste des dépenses" peut en fait être développé des deux manières, tout dépend du projet.

Si la liste des dépenses est unique (ont à qu’une liste qui ne change pas), alors on récupère la liste des dépenses via un service directement dans le composant. On pourrait aussi passer en paramètre de ce composant l’ID du compte bancaire sur lequel il y à les dépenses.

En revanche, si cette liste est générique, et permet d’afficher les dépenses, mais aussi les entrées, et à plusieurs endroits de l’application, alors il vaut mieux récupérer les données (toujours via un service) dans le composant parent (par exemple, la page).

C’est bien ça ?

En tout cas, ça me paraît plus clair. Je n’avais tout simplement pas cette notion de "type de composant".

Exactement, tu auras difficilement tous tes composants réutilisables à 100%. Après ça n’empêche pas de les rendre au maximum modulable, même pour ceux "fonctionnels". Au moment d’une refactorisation, tu vas sûrement de rendre compte qu’il est plus simple de modifier un peu ton composant plutôt que de recréer un simili. Je pense par exemple à un espace de connexion - ton composant pourrait prendre la largeur intégrale de la page quand tu l’affiches sur la page /connexion et être réduit quand il est affiché dans le bandeau du haut (avec le menu). Techniquement ce n’est pas transposable sur un autre projet - à moins de garder toute la procédure de connexion, du service jusqu’à l’API - mais c’est réutilisable ailleurs dans le site sous une autre forme.