Maison > Article > interface Web > Couplage lâche de la couche d'interface utilisateur dans le développement Web
Cette fois, je vais vous présenter le couplage lâche de la couche UI dans le développement Web. Quelles sont les précautions lors de l'utilisation du couplage lâche de la couche UI dans le développement Web. Voici des cas pratiques, prenons un. regarder.
Dans le développement Web, l'interface utilisateur est définie par trois couches isolées et interagissant les unes avec les autres.
HTML est utilisé pour définir les données et la sémantique de la page
CSS est utilisé pour ajouter des styles à la page et créer des fonctionnalités visuelles
JS est utilisé pour ajouter un comportement à la page pour la rendre plus Interactivité
Concernant le couplage lâche, permettez-moi de dire quelques mots. Lorsque vous pouvez modifier un composant sans changer d’autres composants, vous obtenez un couplage lâche. Pour les grands systèmes multi-personnes, où de nombreuses personnes sont impliquées dans la maintenance du code, le couplage lâche est essentiel à la maintenabilité du code. Vous voulez absolument que les développeurs ne cassent pas le code des autres lorsqu'ils modifient une partie du code. Lorsque le contenu de chaque composant d’un grand système est limité, un couplage lâche est obtenu. Essentiellement, chaque composant doit être suffisamment fin pour garantir un couplage lâche. Moins les composants sont connus, mieux il est possible de former le système global.
Une chose à noter : les composants travaillant ensemble ne peuvent pas atteindre "aucun couplage". Dans tous les systèmes, les composants partagent certaines informations pour faire leur travail. Il est facile de comprendre que notre objectif est de garantir que les modifications apportées à un composant n'affectent pas régulièrement d'autres pièces.
Si une interface utilisateur Web est faiblement couplée, elle est facile à déboguer. Les problèmes liés au texte ou à la structure peuvent être localisés en effectuant une recherche HTML. Lorsqu'un problème lié au style survient, vous savez que le problème vient du CSS. Enfin, pour ces problèmes de comportement, votre capacité à accéder directement à JS pour trouver le problème est un élément essentiel de la maintenabilité des interfaces Web.
A l'ère des pages Web, nous prônons la séparation des trois couches HTML/CSS/JS. Par exemple, il est interdit d'utiliser les attributs inline du DOM pour lier des auditeurs, 3078d2a3d278fa3322f992676d8f3f84test120d611986108da972f06c8ab0c8bab5Écrire comme ça vous fera pulvériser. Cependant, à l'ère des WebApp, les frameworks MVVM et MVC représentés par React (à proprement parler, React n'est qu'un framework axé sur la couche View), ils recommandent tous d'écrire HTML, CSS et JS ensemble, et vous pouvez souvent voir à le code qui lie l'écouteur d'événements en ligne.
Vous ne pouvez pas vous empêcher de vous demander si nous reculons ?
L'histoire tourne parfois en rond, et au premier coup d'oeil j'ai cru que j'y retournais. En fait, la spirale s’est inversée et se trouve à un nouveau point de départ. ——Yu Bo "Évolution du modèle de R&D Web"
À l'ère traditionnelle des pages Web, la prise en charge des composants n'était pas élevée, tant au niveau du langage qu'au niveau du framework. Pensez-y, il n'y a pas de JS qui ne le fasse pas. prennent en charge nativement les modules (avant l'ère ES6) et jQuery, donc afin d'éviter d'augmenter les coûts de maintenance, la meilleure pratique de séparation à trois couches est recommandée. Avec l’essor d’ES6 et du framework front-end MV*, l’ensemble du modèle de développement front-end a changé. Vous constaterez que le front-end ne consiste pas seulement à écrire des pages, mais également à écrire davantage de WebApps. L'échelle et la complexité des applications sont différentes de celles de l'ère des pages Web.
React est un représentant très typique. Il propose d'utiliser JSX pour écrire du HTML, en écrivant directement ensemble la structure et la logique de la page. Si cela était placé à l'ère des pages Web, je pense qu'il serait directement considéré comme un matériel pédagogique anti-modèle typique, mais à l'ère des applications Web, il est accepté et utilisé par la plupart des gens ; Y compris CSS dans JS proposé par l'équipe React, ils souhaitent également écrire CSS dans JS afin que le développement front-end soit complètement dominé par JS et que la composantisation soit effectuée de manière plus approfondie (je n'ai pas fait de recherche et de compréhension approfondies de CSS dans JS , et il n'y a pas de véritable expérience pratique à grande échelle dans le projet, donc maintenant je maintiens toujours une attitude attentiste et je continue à utiliser les précédents SASS et LESS pour le développement CSS).
Bien que les modèles de développement des deux ères du Web aient radicalement changé, il existe encore quelques principes généraux que vous devez suivre concernant la conception du couplage lâche à trois couches :
Extraire JS du CSS. Les premiers navigateurs IE8 et précédents autorisaient l'écriture de JS en CSS (si vous n'écrivez pas d'exemple, c'est un anti-modèle, il vaut mieux ne pas vous en souvenir). Cela entraînera des problèmes de performances, et ce qui est encore plus effrayant, c'est). qu'il sera difficile de maintenir à l'avenir. Mais je crois qu'aucun d'entre vous ici n'aura accès à ce genre de code, ce qui est très bien.
Extraire le CSS de JS. Ce n'est pas que vous ne pouvez pas modifier le CSS dans JS. Cela ne signifie pas que vous n'êtes pas autorisé à modifier le style directement. Au lieu de cela, vous pouvez modifier le style indirectement en modifiant la classe. Voir l'exemple suivant :
// 不好的写法element.style.color = 'red'; element.style.left = '10px'; element.style.top = '100px'; element.style.visibility = 'visible';// 好的写法.reveal { color: red; left: 10px; top: 100px; visibility: visible; } element.classList.add('.reveal');
Parce que le CSS className peut devenir un pont de communication entre CSS et JS. Dans le cycle de vie de la page, JS peut ajouter et supprimer le className de l'élément à volonté. Le style défini par className est dans le code CSS. A tout moment, les styles en CSS peuvent être modifiés sans avoir à mettre à jour JS. JS ne doit pas manipuler les styles directement afin de maintenir un couplage lâche avec CSS.
Il existe une situation où l'utilisation de l'attribut style est acceptable : lorsque vous devez positionner un élément sur la page par rapport à un autre élément ou repositionner la page entière. Ce calcul ne peut pas être effectué en CSS, vous pouvez donc utiliser style.top, style.left, style.bottom et style.rght pour positionner correctement l'élément. Définissez les attributs par défaut de cet élément en CSS, et modifiez ces valeurs par défaut en Javascript.
Compte tenu de la situation actuelle dans laquelle le front-end a écrit HTML et JS ensemble, je ne parlerai pas de la pratique consistant à séparer les deux dans le livre original. Mais, après avoir dit toutes ces absurdités, rappelez-vous ceci : la prévisibilité conduit à des tests et un développement plus rapides, et savoir (plutôt que deviner) par où commencer le débogage des bogues permettra de résoudre le problème plus rapidement et la qualité globale de votre code sera meilleure.
Je pense que vous maîtrisez la méthode après avoir lu le cas dans cet article. Pour des informations plus intéressantes, veuillez prêter attention aux autres articles connexes sur le site Web chinois de php !
Lecture recommandée :
Comment utiliser JS pour passer par référence et passer par valeur
Comment créer un nœud Interface .js
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!