Prévenir/refactoriser les chaînages conditionnels

L'une des odeurs de code les plus courantes lors du développement d'applications JavaScript est l'excès de chaînage conditionnel. Dans cet article, je souhaite expliquer comment prévenir ces cas grâce à l'architecture et au code.

Table des matières

1. Présentation
2. Comprendre les chaînes conditionnelles
3. Le problème des chaînes conditionnelles
4. Refactorisation des chaînes conditionnelles
5. Prévenir les chaînes conditionnelles grâce à l'architecture
6. Meilleures pratiques pour le développement front-end
7. Conclusion

Qu'est-ce qu'une chaîne conditionnelle ?

Le chaînage conditionnel excessif est une odeur de code courante dans les applications JavaScript. Cet article explore comment prévenir et refactoriser ces cas grâce à une architecture et des pratiques de codage améliorées.

Les chaînes conditionnelles sont des opérateurs logiques excessifs utilisés pour exprimer des conditions dans des fonctions ou des méthodes. Regardons un exemple utilisant une application React :

Comme vous pouvez le voir dans l'exemple ci-dessus, il existe une chaîne de trois conditions uniquement pour dicter la manière dont ce code doit être rendu.
Les conditions sont :

1. Si la liste des sports comporte des éléments, l'élément par défaut doit être rendu ;
2. Si l'état de chargement du composant est vrai, un squelette de chargement doit être rendu ;
3. S'il n'y a aucun élément dans la liste des sports, un état vide doit être rendu.

Dans ce code, il y a deux problèmes principaux :

1. Lorsque nous vérifions la longueur d'un tableau et utilisons l'opérateur "&&", nous disons à javascript qu'il doit restituer le composant s'il existe une valeur liée à la longueur du tableau. S'il n'y a pas de tableau, cette valeur doit être nulle ou indéfinie, mais si le tableau existe et que sa longueur est nulle, le nombre zéro sera rendu à la place des éléments, car vous demandez à javascript de restituer la valeur liée au longueur du tableau.
2. Il n'est pas nécessaire d'utiliser une chaîne pour contrôler le rendu de ces deux éléments. L'ajout d'une condition avant le rendu de l'état "par défaut" du composant sera une manière plus élégante de travailler avec cette situation.

Refactorisation

Cela étant dit, la version refactorisée du code ci-dessus est :

C'est l'une des nombreuses façons de gérer les chaînages conditionnels à l'aide des opérateurs logiques de JavaScript. Comme vous pouvez le voir dans le code ci-dessus, j'ai utilisé une approche non courante pour résoudre l'excès conditionnel du code.

Le !! L'opérateur en JavaScript est utilisé pour contraindre une valeur à un booléen. Il profite du fait que JavaScript a des valeurs véridiques et fausses. Le premier ! L'opérateur annule la valeur, transformant les valeurs véridiques en fausses et les valeurs fausses en vraies. La seconde ! l'annule à nouveau, ce qui donne une représentation booléenne de la valeur d'origine. Ceci est souvent utilisé pour convertir des valeurs telles que des chaînes, des nombres ou des objets en une valeur booléenne (vrai ou faux), en fonction de leur véracité ou de leur fausseté.

Par exemple :

!! "Bonjour" est évalué à vrai car les chaînes non vides sont véridiques.
!!0 est évalué à faux car 0 est faux.

Empêcher que cela se produise grâce à des décisions architecturales

Vous ne devez pas prendre cela comme une règle, mais dans la plupart des cas où des chaînes conditionnelles sont créées, l'excès de conditions tente d'analyser et de gérer des valeurs dynamiques, car si vous avez affaire à des valeurs statiques, l'implémentation a tendance à pour être beaucoup plus simple et direct.

Lorsque vous modélisez une base de données, vous devez avoir quelques inquiétudes concernant les dépendances du logiciel.

Les gens apprennent généralement ce type d'étude de dépendance grâce à leurs études universitaires en informatique, mais je vais l'illustrer.

Il existe deux types de dépendances aux logiciels :

1. Dépendances fonctionnelles - ces dépendances affectent directement l'utilisateur, puisqu'il s'agit des fonctionnalités avec lesquelles les utilisateurs interagissent, telles que les boutons, les écrans, les entrées, les formulaires, etc.
2. Dépendances non fonctionnelles - ces dépendances ne sont généralement pas remarquées par les utilisateurs ordinaires car il s'agit principalement de dépendances back-end, telles que la gestion des erreurs, les conditions, les règles de gestion, les validations, etc.

Prévenir un contrôle excessif en amont

Votre back-end doit être responsable de toutes les parties logiques de votre système, donc la majorité de vos dépendances fonctionnelles doivent être gérées par des fonctions back-end, et non par des écrans front-end ou des interactions utilisateur.

Lorsque vous commencez à développer une nouvelle fonctionnalité et à comprendre ce dont elle a besoin pour fonctionner, comme les accessoires, les interfaces et les paramètres, vous devez avoir à l'esprit ce qui sera requis, ce qui sera facultatif et ce qui ne doit pas l'être. utilisé.

Vous devez utiliser l'exemple ci-dessus comme exemple de ce qu'il ne faut pas faire lors de vos sessions de développement. Comme vous pouvez le voir, cette interface n'a que des paramètres facultatifs, mais je doute que ce composant ait uniquement des variables "peut-être" attachées.

Vous devez comprendre comment votre composant est censé fonctionner avant de le développer et de transmettre beaucoup de code déroutant à votre application frontale. Au lieu de gérer de nombreuses conditions, c'est plus facile si vous décidez simplement : ce qui sera utilisé par le composant et ce qui ne le sera pas.

Après y avoir mieux réfléchi, vous arriverez à quelque chose comme ceci :

Maintenant, l'interface n'a que des paramètres obligatoires qui seront certainement utilisés tout au long de la durée de vie du composant dans votre application, sans beaucoup de paramètres facultatifs qui ne pourraient jamais être définis ou utilisés comme le composant d'avant.

Conclusion

La prévention et la refactorisation des chaînes conditionnelles conduisent à un code plus propre et plus maintenable. En comprenant les exigences de votre composant, en déplaçant la logique vers le back-end le cas échéant et en concevant des interfaces claires, vous pouvez réduire considérablement le besoin de chaînes conditionnelles complexes dans votre code front-end.

Photo par Samsung Memory sur Unsplash

Ce qui précède est le contenu détaillé de. pour plus d'informations, suivez d'autres articles connexes sur le site Web de PHP en chinois!