Découpler HTML, CSS et JS-js tutoriel-php.cn

Actuellement sur Internet, tout site Web ou application légèrement complexe contiendra beaucoup de HTML, CSS et JavaScript. À mesure que l’utilisation d’Internet évolue et que notre dépendance à son égard augmente, il est indispensable d’avoir un plan pour organiser et maintenir votre code front-end.

Certaines des grandes sociétés Internet d'aujourd'hui, alors que de plus en plus de personnes seront exposées à un nombre croissant de codes front-end, elles essaieront d'adhérer à la modularité du code. Changer une partie du code du programme de cette manière n'affectera pas trop par inadvertance l'exécution des parties ultérieures non liées.

Prévenir les conséquences involontaires n'est pas un problème facile à résoudre, d'autant plus que HTML, CSS et JavaScript sont intrinsèquement interdépendants. Pire encore, lorsqu'il s'agit de code front-end, certains principes informatiques traditionnels, tels que la séparation des préoccupations, utilisée depuis longtemps dans le développement côté serveur, sont rarement abordés.

Dans cet article, je parlerai de ce que j'ai appris sur la façon de découpler mon code HTML, CSS et JavaScript. D'après l'expérience personnelle et celle des autres, la meilleure façon d'y parvenir n'est pas évidente, est souvent peu intuitive et va parfois à l'encontre de nombreuses soi-disant meilleures pratiques.

Cible

Il y aura toujours un couplage entre HTML, CSS et JavaScript. Quoi qu’il en soit, ces technologies sont intrinsèquement conçues pour interagir les unes avec les autres. Par exemple, un effet de transition Flash peut être défini dans une feuille de style avec un sélecteur de classe, mais il est souvent initialisé par HTML et déclenché par une interaction de l'utilisateur, telle que l'écriture de JavaScript. Étant donné qu'un certain couplage de code frontal est inévitable, votre objectif ne doit pas être simplement d'éliminer le couplage, mais de réduire les couplages de dépendances inutiles entre les codes. Un développeur back-end devrait être en mesure d'apporter des modifications au balisage dans les modèles HTML sans se soucier d'enfreindre accidentellement les règles CSS ou certaines fonctionnalités JavaScript. À mesure que les équipes Web d’aujourd’hui deviennent plus grandes et plus spécialisées, cet objectif est plus grand que jamais.

Anti-modèle

Un couplage étroit dans le code frontal n'est pas toujours évident. La complication est que d’un côté, cela peut sembler faiblement couplé, mais d’un autre côté, il peut être étroitement couplé. Vous trouverez ci-dessous tous les anti-modèles que j'ai réalisés ou vus à plusieurs reprises et que j'ai appris de mes erreurs. Pour chaque modèle, je vais essayer d'expliquer pourquoi le couplage est si mauvais et indiquer comment l'éviter.

Sélecteurs trop complexes

CSS Zen Garden a montré au monde que vous pouvez changer complètement l'apparence d'un site Web entier sans changer une seule balise HTML. Ceci est typique du mouvement du Web sémantique, dont l’un des grands principes est d’éviter d’utiliser des classes de présentation. À première vue, CSS Zen Garden peut ressembler à un bon exemple de découplage ; après tout, séparer le style du langage de balisage est tout son intérêt. Cependant, si vous faites cela, le problème se pose. Vous aurez souvent besoin d'avoir un tel sélecteur dans votre feuille de style, comme suit :

#sidebar section:first-child h3 + p { }

Copier après la connexion

CSS Zen Garden, bien que HTML soit presque complètement identique à CSS Separation. , mais CSS sera fortement couplé au HTML, ce qui nécessite une compréhension approfondie de la structure du langage de balisage. Cela peut ne pas sembler être une mauvaise chose, surtout si quelqu'un gère le CSS et doit également maintenir le HTML, mais une fois que vous ajoutez beaucoup de personnes au mélange, la situation devient ingérable. Si un développeur ajoute un

avant la première

dans certaines circonstances, la règle ci-dessus ne prendra pas effet, mais il ne sait pas pourquoi.

Tant que le balisage de votre site change rarement, CSS Zen Garden est une très bonne idée. Mais ce n’est pas nécessairement le cas des applications Web actuelles. Par rapport aux sélecteurs CSS longs et compliqués, le meilleur moyen consiste à ajouter un ou plusieurs sélecteurs de classe à l'élément racine du composant visuel lui-même. Par exemple, si la barre latérale comporte des sous-menus, il vous suffit d'ajouter un sélecteur de classe de sous-menu pour chaque élément de sous-menu au lieu d'utiliser ce formulaire :

ul.sidebar > li > ul {
  /* submenu styles */
}

Copier après la connexion

Le résultat de cette approche est que plus de code est nécessaire dans le HTML. Sans les sélecteurs de classe en HTML, les développeurs peu familiers avec CSS ne sauraient pas comment les modifications apportées au HTML affectent les autres codes. D'un autre côté, l'utilisation de sélecteurs de classe en HTML indique très clairement quels styles ou fonctionnalités sont utilisés.

Les responsabilités de plusieurs sélecteurs de classe

Un sélecteur de classe est souvent utilisé à la fois comme crochet de style et comme crochet JavaScript. Bien que cela puisse paraître économique (car au moins une balise de classe est réduite), en fait, cela couple les performances et les fonctionnalités de l’élément.

<button class="add-item">Add to Cart</button>

Copier après la connexion

L'exemple ci-dessus décrit un bouton « Ajouter au panier » avec le style de classe d'ajout d'élément.

如果开发者想为此元素添加一个单击事件监听器，用已经存在的类选择器作为钩子非常的容易。我的意思是，既然已经存在了一个，为何要添加另一个呢？但是想想看，有很多像这样的按钮，遍布了整个网站，都调用了相同的JavaScript功能。再想想看，如果市场团队想要其中一个和其它看起来完全不同但功能相同的按钮呢。也许这样就需要更多显著的色彩了。

问题就来了，因为监听单击事件的JavaScript代码希望add-item类选择器被使用到，但是你新的按钮又无法使用这个样式(或者它必须清除所有声明的，然后再重置新的样式)。还有，如果你测试的代码同时也希望使用add-item类选择器，那么你不得不要去更新那么代码用到的地方。更糟糕的是，如果这个”添加到购物车”功能不仅仅是当前应用用到的话，也就是说，把这份代码抽象出来作为一个独立的模块，那么即使一个简单的样式修改，可能会在完全不同的应用中引发问题。

使用javaScript钩子最好的(事实上也是比较鼓励的)做法是，如果你需要这么做，使用一种方式来避免样式和行为类选择器之间的耦合。

我的个人建议是让JavaScript钩子使用前缀，比如：js-*。这样的话，当开发者在HTML源代码中看到这样的类选择器，他就完全明白个中原因了。所以，上述的”添加到购物车”的例子可以重写成这样：

<button class="js-add-to-cart add-item">Add to Cart</button>

Copier après la connexion

现在，如果需要一个看起来不同的按钮，你可以很简单地修改下样式类选择器，而不管行为的类选择器。

<button class="js-add-to-cart add-item-special">Add to Cart</button>

Copier après la connexion

JavaScript更多的样式操作

JavaScript能用类选择器去DOM中查找元素，同样，它也能通过增加或移除类选择器来改变元素的样式。但如果这些类选择器和当初加载页面时不同的话也会有问题。当JavaScript代码使用太多的组成样式操作时，那些CSS开发者就会轻易去改变样式表，却不知道破坏了关键功能。也并不是说，JavaScript不应该在用户交互之后改变可视化组件的外观，而是如果这么做，就应该使用一种一致的接口，应该使用和默认样式不一致的类选择器。

和js-*前缀的类选择器类似，我推荐使用is-*前缀的类选择器来定义那些要改变可视化组件的状态，这样的CSS规则可以像这样：

.pop-up.is-visible { }

Copier après la connexion

注意到状态类选择器(is-visible)是连接在组件类选择器(pop-up)后，这很重要。因为状态规则是描述一个的状态，不应该单独列出。如此不同就可以用来区分更多和默认组件样式不同的状态样式。

另外，可以让我们可以编写测试场景来保证像is-*这样的前缀约定是否遵从。一种测试这些规则的方式是使用CSSLint和HTML Inspector。

更多关于特定状态类选择可以查阅Jonathan Snnok编写的非常优秀的SMACSS书籍。

JavaScript”选择器”

jQuery和新的API，像document.querySelectorAll，让用户非常简单地通过一种他们已经非常熟悉的语言–CSS选择器来查找DOM中的元素。虽然如此强大，但同样有CSS选择器已经存在的相同的问题。JavaScript选择器不应过度依赖于DOM结构。这样的选择器非常慢，并且需要更深入认识HTML知识。

就第一个例子来讲，负责HTML模板的开发者应该能在标记上做基本的改动，而不需担心破坏基本的功能。如果有个功能会被破坏，那么它就应该在标记上显而易见。

我已经提及到应该用js-*前缀的类选择器来表示JavaScript钩子。另外针对消除样式和功能类选择器之间的二义性，需要在标记中表达出来。当某人编写HTML看到js-*前缀的类选择器时，他就会明白这是别有用途的。但如果JavaScript代码使用特定的标记结构查找元素时，正在触发的功能在标记上就不那么明显了。

为了避免使用冗长而又复杂的选择器遍历DOM，坚持使用单一的类或者ID选择器。考虑以下代码：

var saveBtn = document.querySelector("#modal div:last-child > button:last-child")

Copier après la connexion

这么长的选择器是可以节省你在HTML中添加一个类选择器，但同样让你的代码对于标记更改非常容易受到影响。如果设计者突然决定要把保持按钮放在左边，而让取消按钮放在右边，这样的选择器就不再匹配了。

一个更好的方式(使用上述的前缀方法)是仅仅使用类选择器。

var saveBtn = document.querySelector(".js-save-btn")

Copier après la connexion

现在标记可以更改它想改的，并且只要类选择还是在正确的元素上，一切都会很正常。

类选择器就是你的契约

L'utilisation de sélecteurs de classe appropriés et de conventions de nom de classe prévisibles peut réduire le couplage entre presque tous les types de HTML, CSS et JavaScript. Au début, l'utilisation de nombreux sélecteurs de classe dans le balisage peut sembler le signe d'un couplage fort, puisque vous devez connaître les noms de nombreux sélecteurs de classe pour pouvoir restituer le code HTML. Mais je trouve que l’utilisation de sélecteurs de classe est très similaire au modèle d’événement ou d’observateur dans la conception de programmation traditionnelle. Dans la programmation événementielle, au lieu d'appeler l'objet B directement sur l'objet A, l'objet A publie simplement un événement spécifique dans l'environnement fourni, et l'objet B peut alors s'abonner à cet événement. De cette façon, l’objet B n’a pas besoin de savoir quoi que ce soit sur l’interface de l’objet A, mais a seulement besoin de savoir quels événements écouter. Il va de soi que le système d'événements nécessite une certaine forme de couplage, car l'objet B a besoin de connaître le nom de l'événement auquel s'abonner, mais comparé à l'objet A qui a besoin de connaître les méthodes publiques de l'objet B, il s'agit d'un couplage déjà plus lâche.

Les sélecteurs de classe HTML sont tous très similaires. Contrairement à la définition de sélecteurs complexes dans les fichiers CSS (tout comme l'interface interne du HTML), il est possible de définir simplement l'apparence d'un composant visuel via un seul sélecteur de classe. Le fichier CSS n'a pas besoin de se soucier de savoir si le HTML utilise ou non des sélecteurs de classe. De même, JavaScript n'utilise pas de fonctions complexes de traversée du DOM qui nécessitent une compréhension plus approfondie de la structure HTML, mais écoute uniquement les interactions de l'utilisateur sur les éléments portant le même nom de classe. Les sélecteurs de classe doivent être comme le ciment qui maintient ensemble HTML, CSS et JavaScript. Je sais par expérience personnelle qu’ils constituent également le moyen le plus simple et le meilleur de connecter les trois technologies sans trop les mélanger.

Futur

Le groupe de travail sur la technologie hypertexte Web (WHATWG) travaille sur une spécification pour les composants Web qui permettra aux développeurs de lier HTML, CSS et JavaScript Déterminé ensemble en tant que composant ou module distinct et interagit avec d'autres éléments de la page pour l'encapsuler. Si cette spécification avait été implémentée dans une majorité de navigateurs, alors bon nombre des suggestions que je propose dans cet article deviendraient moins importantes (car il deviendrait clair avec qui le code interagit, mais peu importe, comprendre ces principes et pourquoi) ; ils sont nécessaires et restent importants. Même si ces pratiques deviendront moins importantes à l’ère des composants Web, la théorie reste valable. Les pratiques utilisées dans les grandes équipes et les grandes applications s'appliquent toujours à l'écriture de petits modules, mais pas l'inverse.

Conclusion

La caractéristique du HTML, CSS et JavaScript maintenables est que chaque développeur peut écrire facilement et en toute confiance chaque partie de la base de code, sans se soucier de cela ces modifications affecteront par inadvertance d’autres parties non liées. L'un des meilleurs moyens d'éviter de telles conséquences involontaires est de lui donner un ensemble prévisible et humain de noms de sélecteur de classe qui transmettent sa signification et peuvent être utilisés par tout développeur qui le rencontre. Les trois technologies sont combinées.

Pour éviter les anti-modèles ci-dessus, veuillez garder les principes suivants à l'esprit :

1. En CSS et JavaScript, donnez la priorité aux sélecteurs de composants et de classes de comportement explicites, et aux sélecteurs CSS non complexes. .

2. Nommez les composants en fonction de ce qu'ils sont, et non de l'endroit où ils se trouvent

3. N'utilisez pas le même sélecteur de classe pour le style et le comportement

4. entre le style d'état et le style par défaut

L'utilisation de sélecteurs de classe en HTML nécessite souvent de nombreux sélecteurs de classe qui doivent être affichés, mais ce que vous gagnez, c'est la prévisibilité et la maintenabilité, ce qui mérite d'être reconnu. Après tout, ajouter des sélecteurs de classe au HTML est assez simple et nécessite peu de compétences de la part du développeur. Extrait des mots originaux de Nicolas Gallagher :

Quand vous cherchez un moyen de réduire le temps passé à écrire et modifier du CSS pour faire du HTML et du CSS, voilà ce qu'il faut implique Vous devez accepter que si vous souhaitez changer le style, vous ne voulez pas passer plus de temps à changer le sélecteur de classe sur l'élément HTML. Cela présente une certaine utilité pour les développeurs front-end et back-end, et n'importe qui peut réorganiser les briques LEGO pré-construites. Alors personne ne montrera la magie du CSS.

Pour plus d'articles sur le découplage HTML, CSS et JS, veuillez faire attention au site Web PHP chinois !