Pour ceux qui n'aiment pas les longues introductions, passons directement aux conclusions - écrivez des tests pour vos composants. Sérieusement, c'est tout ce que je veux dire. Mais ne prenons pas cela trop au sérieux, imaginons que ce sont les conclusions d'un théorème, un théorème frontal. Et maintenant, nous devrons trouver des preuves.
Alors, imaginons. Qu'est-ce qui est commun dans le développement informatique, pas seulement dans le frontend, le backend ou la conception, les langages de programmation, la gestion, les méthodologies et ainsi de suite? Je suppose qu'il y a un seul principe principal - la décomposition et les composants.
Que nous le voulions ou non, que nous comprenions ce que nous écrivons ou non, nous travaillons avec des composants, nous décomposons toujours les tâches en plus petites.
Et en se réunissant pour la millionième fois pour écrire la prochaine implémentation de la table pour notre magnifique kit d'interface utilisateur, je me suis dit - quel travail préliminaire dois-je faire? Que faut-il exactement écrire? Et par où commencer?
Après avoir parlé avec des coéquipiers, j'ai entendu quelques conseils. J'en ai vraiment aimé un. Comme je suis fan de singularité et d'un peu de graphql, on m'a demandé de ne rien écrire du tout. Utilisez la balise {table} et un réseau de neurones traitera cette table, créera une requête graphql et remplira la table avec des données. Facile :).
Mais comme on dit - «il y a une faille fatale dans n'importe quel système», j'ai commencé à réfléchir à «comment inventer ma propre roue». Et les gens intelligents ont déjà tout inventé devant nous. Nous, les milléniaux, ne pouvons que réorganiser les assiettes et nommer les choses différemment.
Je suis prêt à présenter mon propre ensemble de principes de prototypage de kits d'interface utilisateur - IDOLS! Jetons un coup d'oeil!
Je représente la ségrégation d'interface, D signifie l'inversion de dépendance, O signifie ... je plaisante, bien sûr, c'est SOLIDE
Toutes les tentatives de formaliser le travail avec des composants sont réduites à cela. Ces principes peuvent être étendus indéfiniment, mais tout est toujours le résultat final est réduit à ces cinq. Si nous parlons bien sûr de POO ou CBP (programmation par composants).
Chargeons ces principes dans notre «RAM» et passons en revue les points.
S - Responsabilité unique
Hmm, s'il te plait ne le fais pas ...
Utilisez un composant spécial pour différents cas. Vous ne devez PAS créer un composant, qui sera capable de couper quelque chose et d'arracher quelque chose en même temps. Faites deux morceaux différents.
O - Ouvert / Fermé
Le principe dit que vos composants doivent être ouverts pour les améliorations et fermés pour les modifications, en d'autres termes, vous pouvez réutiliser votre composant dans un autre composant, mais vous ne devez pas changer votre composant s'il respecte déjà le principe de la responsabilité unique.
L - Substitution de Liskov
Petite extension du principe précédent, toute instance d'une sous-classe peut être utilisée à la place d'une instance de la classe de base. Je ne sais pas comment ce principe s'inscrit dans le contexte des composants, il s'agit très probablement d'une duplication du principe précédent.
I - Ségrégation des interfaces
Nous en parlerons encore plus loin, maintenant nous pouvons dire qu'il vaut mieux donner à l'autre développeur beaucoup de petites interfaces qu'une grande mais pour tout. Comparons les exemples ci-dessous.
Tout se configure en un seul endroit, non maintenable, non réutilisable ...
Tout en tant que constructeur, assemblez comme vous le souhaitez et commodément
D - Inversion de dépendance
Le principe selon lequel les différentes parties de l'application ne doivent rien savoir les unes des autres et ne doivent être héritées que par le biais d'interfaces communes. Ici, nous parlons davantage de réutilisation et de réduction de la connectivité des composants. Le composant du tableau n'a pas besoin de savoir d'où et comment les données proviennent, il a seulement besoin de connaître le DataLoader conditionnel, qui peut être n'importe quoi.
Mais un point de vue ne nous suffit pas. Puisque dans cette situation, il est très facile de devenir l'otage de cette idée. Par conséquent, nous considérons le développement de composants d'un autre côté, du côté de la conception.
Dans ce cas, nous considérerons l'une des approches de conception de plus en plus populaires, à savoir la conception atomique. Relativement parlant, la conception atomique est une autre façon de décomposer les éléments de l'interface utilisateur en les comparant avec une hiérarchie de la physique et de la biologie.
Jetons donc un coup d'œil à la conception atomique.
Jetons
Le premier niveau est les jetons, quelqu'un inclut cela dans le modèle, quelqu'un non, mais cela vaut la peine d'être mentionné. Les jetons (couleurs, tailles de police, espacements, animations) sont toutes les primitives que nous pouvons réutiliser sur n'importe quelle plateforme.
Il convient de noter que plus nous sommes élevés dans la hiérarchie de la conception atomique, plus la réutilisation diminue. Mais plus à ce sujet plus tard.
Atomes
Viennent ensuite les atomes (composants simples sans logique, entrées, boutons). Le premier niveau est l'endroit où les composants apparaissent et ce qu'ils produisent. Les atomes n'ont aucun état, affichent uniquement un balisage de style statique.
Molécules
Les atomes s'assemblent ensuite en molécules (liaisons composantes plus complexes). Les molécules peuvent avoir leur propre état, mais ce n'est pas un état commercial, il peut s'agir d'un état de configuration (comme isOpen). Nous pouvons deviner que les molécules ressemblent plus à un proxy entre le premier état des affaires et la façon dont nous alignons le contenu de nos atomes ou enfants en fonction de cet état.
Les molécules sont le dernier niveau où nous pouvons rencontrer le style.
Organismes
Les molécules constituent des organismes (groupes de travail intégrés de composants), par exemple un en-tête, un pied de page, etc. Les organismes ne savent rien des autres organismes et styles, c'est nos «conteneurs d'ADN» notre logique métier, qui savent le montrer et quand il faut le changer.
Modèles / Pages
Le dernier niveau de conception atomique. Ce niveau représente les groupes d'organismes inclus dans la page actuelle.
Nous pouvons faire la composition des organismes sur la page via des molécules, puis appeler cette page comme «mise en page» et la réutiliser en changeant nos organismes à l'intérieur.
En utilisant ces deux approches (SOLID et Atomic), nous essaierons de formuler quelques recommandations lors du développement de composants. Donc, ces recommandations seront nécessaires pour que nous comprenions ce que nous faisons exactement quand nous disons «créer un autre composant».
Étant donné que ces composants fonctionneront avec d'autres développeurs, nous garderons cela à l'esprit lorsque nous installerons l'interface et l'API.
Nous pouvons commencer à développer notre interface idéale.
La première chose à faire est de ne pas commencer à développer une interface idéale. L'interface idéale est son manque. Une interface est un obstacle entre ce que vous avez fait et quand elle commence à fonctionner. C'est une douleur qui doit être évitée.
Ainsi, la meilleure solution serait la suivante:
Cela nous amène en douceur à ce qui suit:
1. Déterminez l'état du composant
Si un développeur qui utilise ce composant le voit pour la première fois, faites-en un peu d'intégration, traduisez le composant dans de nouveaux états à mesure que la complexité des paramètres augmente et informez-en le développeur.
Les états peuvent être complètement différents à différents moments.
Vide → Téléchargement → Chargement → Chargement d'une autre pièce → Complètement chargé → Erreur, etc.
Guidez les développeurs à travers toutes les combinaisons possibles d'états, enseignez-leur pendant qu'ils travaillent.
Lorsque l'on traite des problèmes d'état, on tombe involontairement sur le problème des états par défaut. À cause de cela, la deuxième recommandation.
2. Définissez les valeurs par défaut
Avec cet article, vous pouvez tuer deux oiseaux avec une pierre, vous fournissez non seulement des informations de base au développeur sur ce qui se passe avec l'application mais pour vous, l'absence de l'une ou l'autre variable ne sera pas une surprise qui casse tout. De plus, de vilains contrôles de leur présence ne sont en principe pas nécessaires.
De plus, si le développeur souhaite toujours ajouter des paramètres, il est nécessaire de l'aider à ce sujet, et de ne pas interférer.
Compte tenu de la théorie de Richard Gregory, les gens explorent le monde qui les entoure sur la base d'expériences visuelles antérieures. Et si votre composant change quelque chose sous son capot et que vous souhaitez en informer le développeur, appelez vos hooks et rappels de manière prévisible.
3. Pas besoin de réinventer la roue
Pas changePasswordInputValue, mais onChange, car si c'est votre "molécule", il sera toujours clair ce que la valeur va changer.
Eh bien, essayez de suivre les règles générales de dénomination, le préfixe on pour les événements, les verbes pour les actions, et si vous utilisez le drapeau booléen isDisabled à un endroit, puis utilisez-le partout, vous n'avez plus besoin de isEnabled, soyez cohérent.
La prochaine chose à laquelle vous devez faire attention est que lorsque vous avez fini de travailler sur le composant, vous le transmettez, d'autres développeurs travailleront plus loin avec lui. Et si quelque chose ne va pas avec votre composant, vous devrez commencer un nouveau cercle de développement: le développeur trouve un bogue ou ne peut pas faire quelque chose qu'il veut → ouvre le problème → vous cherchez un temps pour le corriger → pensez à la cohérence → corrigez → mettre à jour les packages → annoncer aux développeurs → mettre à jour les packages → essayer de faire ce qu'ils voulaient il y a une semaine.
4. Essayez de donner aux développeurs autant de contrôle que possible
Comme s'ils avaient écrit ce composant en ce moment - une conclusion directe de l'un des principes de SOLID
Supposons que vous autorisiez la transmission d'un morceau de texte à votre composant. Si ce texte est présent, il sera affiché, mais vous vous souvenez également de la règle sur les états par défaut et écrivez la condition que si le texte n'est pas transmis, affichez le texte par défaut. Donc, sur un bon ton, cela donnera au développeur d'indiquer explicitement que le texte n'est pas nécessaire ici.
Eh bien, si vous considérez qu'en premier lieu nous commençons à travailler avec des composants atomiques, la recommandation suivante vient d'ici.
5. Gardez vos composants propres et secs afin que les abstractions ne fuient pas (KISS).
Comment suivre ça? - tout simplement, n'écrivez pas de code dans votre composant. Seul le modèle et comment il dessine les données d'entrée. Si vous devez faire une carte, filtrer, réduire sur les données, vous avez des constantes qui ne peuvent pas être redéfinies à l'extérieur, votre modèle utilise des littéraux, ce qui est faux - ce n'est plus un atome, mais autre chose, c'est plus difficile à maintenir. Cela doit être évité.
Nous avons donc obtenu une liste de recommandations qu'il serait bon de suivre.
- Définir l'état
- Définir la valeur par défaut
- Ne réinventez pas la roue
- Laissez-les (devs) gouverner
- Keep It Simple, Stupid (KISS)
Mais notre cerveau est tellement agencé qu'après avoir écrit deux ou trois composantes - nous commençons à penser que nous n'avons pas besoin d'examiner cette liste pour vérifier tous les points. Et nous savons que parmi les tâches les plus complexes et les plus faciles, nous choisissons toujours la plus facile car elle fonctionne comme ça. Nous aimons économiser notre énergie, nous en avons besoin, en réserve. Par conséquent, ces listes sont toujours perdues dans la confluence jusqu'à des temps meilleurs, et nous continuons à corriger les bogues vers le maître.
Ce n'est que si nous comprenons qu'il sera plus facile que de ne pas dormir pendant deux semaines d'affilée de rendre sage pour nous, en général, de corriger les bugs en production, nous rendrons la tâche plus difficile (pour des raisons objectives) et plus facile (pour notre raisons).
Comment alors tromper notre cerveau et faire fonctionner les recommandations?
Eh bien, essayons d'automatiser cela.
Automatisation
Nous pouvons utiliser le bundle eslint + lefthook ou tout autre outil git-hooks.
Nous décrivons les règles de la façon dont nous voulons voir nos variables et comment notre code doit être stylisé. Nous interdisons les nombres magiques et les littéraux dans les modèles, nous attendons de nous que nous écrivions des quais pour notre code immédiatement. Nous raccrochons ces vérifications pour un crochet git et recevons des notifications automatiques que notre code est mauvais et doit être mis à jour.
Mais ce n'est pas une solution miracle et nous ne pouvons pas respecter toutes les recommandations. Seulement une partie.
De cette façon, nous ne pouvons pas gérer nos états possibles et ne pouvons garantir que les autres développeurs obtiendront ce qu'ils veulent. Nous pouvons simplement supposer, par exemple, que quelque chose retournera de toute façon (aka valeur par défaut) mais pas plus.
Ensuite, vous pouvez essayer une autre façon. Développer nos composants via SDD. Développement piloté par le livre de contes.
Développement basé sur un livre de contes
Nous avons un fichier d'histoire sous la forme où nous décrivons tous les états possibles du composant. Et un livre d'histoires rassemblant ces histoires.
Nos histoires sur le composant
Comment le livre d'histoires nous montre des histoires
Développer vos composants indépendamment de l'environnement de travail est non seulement un plus pour la pureté des composants, mais cela vous permettra également de voir immédiatement quels états ne sont pas couverts par les tests et lesquels, en principe, sont absents.
Mais au final, cela ne nous donnera pas non plus tout ce que nous voulons.
Il ne reste donc qu'une chose.
Tests et instantanés
Puisque nos composants sont des atomes et des molécules, il devient un plaisir d'écrire des tests unitaires, chaque composant est responsable d'une fonctionnalité que nous pouvons facilement tester en éliminant plusieurs éléments de la liste des recommandations à la fois.
Nous pouvons mettre en place des contrôles instantanés, ce qui nous permettra de surveiller l'état de nos composants et d'apprendre toutes les modifications à l'avenir.
Nous pouvons utiliser un faisceau avec une enzyme pour contrôler nos attentes pendant le développement. Et étrangement, en ce qui concerne les recommandations dans lesquelles nous attendons quelque chose d'un développeur qui écrit du code, seuls les tests et leur écriture conviennent le mieux. Ils ont été littéralement inventés pour cela.
Et c'est parti ...
Rédigez des tests pour vos composants. Merci.