Dès les premières lignes de code, chacun commence à comprendre l'importance de l'organiser correctement et d'optimiser l'espace de travail dans son ensemble.
Peu importe l'industrie dont il faut parler spécifiquement, mais il est important de comprendre que partout où il y a du code, il doit y avoir des règles pour sa création et son stockage.
Dans le premier couple, bien sûr, il peut sembler que le respect de certaines règles et ordonnances ne prend que du temps, ce qui en pratique semble complètement différent. La quintessence de tout principe d'écriture de code est que nous ne l'écrivons pas une fois pour toutes - nous y revenons constamment à des fins d'édition et de modification.
Ce processus peut devenir un véritable problème si le chaos et l'imprévisibilité y règnent. Ce problème peut être aggravé si ce chaos n'a pas été créé par vous, mais par une personne avec laquelle il n'est pas possible d'établir un contact. C'est pour éliminer de telles situations qu'il existe des méthodologies.
Si nous parlons de css, nous pouvons dire avec confiance - chacun de nous utilise une certaine méthodologie, consciemment ou non. Même si une personne n'utilise pas certaines règles et normes, elle a toujours ses propres habitudes et répète constamment des astuces.
Les façons d'écrire du code n'ont pas à être généralement acceptées et normalisées, quelque chose d'autre doit être obligatoire - elles doivent être prévisibles.
La liste des méthodologies auxquelles vous devez prêter attention n'est pas si longue:
-BEM,
-Smacss,
-OOCSS,
-MCSS,
-Atomic CSS
Atomic CSS est peut-être la méthodologie la plus inhabituelle et même quelque peu effrayante, ce qui ne l'empêche heureusement pas d'être très compréhensible et prévisible.
Pour justifier mon choix, je dois reculer un peu.
CSS presque atomique
Il y avait des moments où le répertoire racine du nombre écrasant de projets au stade de la création de l'interface ressemblait à trois fichiers et deux dossiers:
>fonts >img -index.html -style.css -script.js
Mais cette simplicité peut sembler trompeusement pratique, en fait, au moins dans deux de ces trois fichiers, quelque chose de terrible se passait.
Deux choses m'ennuyaient toujours - le désordre et le manque de style. En Css, beaucoup de nuances différentes entrent dans la classification des troubles, mais surtout je n'étais pas satisfait de la répétition constante des mêmes règles et propriétés pour différents sélecteurs.
La première solution à ce problème était la suivante:
- créer un fichier appelé «re-use.css»,
- création d'instructions dans ce fichier, qui en théorie peuvent être nécessaires à plusieurs sélecteurs,
- ajouter différents sélecteurs à la même instruction.
Cela ressemblait à ceci:
... .class { display: inline-block;} .class { text-transform: uppercase;} ...
et a ensuite accepté ce qui suit:
... .menu-link, .primary-button, .form-button, .footer-link, .social-link { display: inline-block;} ...
Bien sûr, cette solution était très peu pratique et heureusement temporaire. Peu tourmenté par la commutation interminable entre les fichiers, et en trouvant le bon endroit dans eux, je suis arrivé à la conclusion qu'il serait beaucoup plus pratique de créer des classes séparées qui sont chacune responsables d'une instruction:
...
.inline-block { display: inline-block;} .block {display: block;} .uppercase {text-transform: uppercase;}
Dans les fichiers html, les balises avec un grand nombre de classes semblaient étranges, mais cette solution me semblait tout à fait acceptable:
<aside class=”sidebar fixed left top w-30 h-100 main-fill”></aside>
En un coup d'œil, il suffit de comprendre qu'il s'agit d'une colonne latérale, à positionnement fixe, sur le côté gauche de l'écran, occupant 30% de sa largeur et 100% de sa hauteur, remplie de la couleur principale.
Tout ce qui concernait les valeurs numériques, principalement celles-ci étaient des retraits externes et internes, j'ai écrit dans le format standard. Pour ce faire, j'ai ajouté une classe distincte qui vient en premier à chaque balise, ou groupe de balises, dans l'exemple ci-dessus c'est la classe «slider».
C'était une approche presque atomique et presque pratique. Plusieurs lacunes l'ont empêché de se mettre à l'aise, les plus importantes étant les situations suivantes:
- lors de la création d'un grand nombre de balises similaires, par exemple, des éléments de liste, j'ai dû copier un grand nombre de classes et cela semblait lourd,
- lors de toute modification, j'ai dû supprimer et ajouter des classes pour chaque élément séparément,
- il y avait beaucoup de classes inutilisées qui étaient difficiles à attraper.
Et puis deux choses sont venues à la rescousse qui ont aidé à résoudre tous les problèmes - c'est le préprocesseur et le moteur de modèle.
Avec leur aide, j'ai modifié ma méthodologie et rendu la mise en page agréable et pratique.
CSS presque parfait
Je vais commencer par le préprocesseur. Son choix n'est pas fondamental, j'ai d'abord utilisé Sass, puis SCSS, et finalement je suis passé à Stylus, car je respecte le minimalisme, et Stylus était aussi minimaliste que possible (scss sera utilisé dans les exemples ci-dessous, en raison de sa popularité).
Donc, la première chose que j'ai faite a été d'écrire des classes supplémentaires qui ressemblaient à de vrais atomes en utilisant la directive @extend:
.flex { display: flex; flex-wrap: no-wrap; } .flex-jc-center { @extend .flex; justify-content: center; } .flex-ai-center { @extend .flex; align-items: center; }
J'ai aimé l'idée, et la directive @extend a causé une ressemblance avec le noyau atomique, à côté duquel il y avait des instructions supplémentaires.
J'ai décidé que l'idée devait être développée et créé un fichier séparé pour les organismes. Organismes que j'ai appelés classes qui incluent plusieurs directives @extend:
.header { @extend .fixed; @extend .w-100; @extend .main-fill; @extend .left; @extend .top; @extend .flex-ai-center; @extend .z-top; }
Ayant créé un petit «zoo» à partir de divers organismes, j'ai décidé de faire quelque chose avec des classes qui nécessitent des valeurs numériques pour l'indentation et la taille.
Les capacités du préprocesseur m'ont aidé à y faire face à nouveau, à l'aide duquel j'ai écrit quelques fonctions et ajouté des variables.
Tout d'abord, j'ai étudié en détail les projets graphiques que je reçois des designers et j'ai révélé un certain nombre de modèles:
- nombre de couleurs pour chaque projet,
- nombre de polices
- nombre de tailles différentes pour le texte et les en-têtes,
- indentation répétée (pour les sections, les boutons, etc.)
La première étape a été d'écrire des fonctions et des mixins pour créer les classes nécessaires:
// px em @function em($pixels, $context: $browser-context) { @return #{$pixels/$context}em };
// $text-size: ( l: 18, m: 16, s: 14, xs: 12 );
@mixin emFonts($list, $n) { // $list – , n – . @each $status, $size in $list { // - &-#{$status} { font-size: em($size - $n); // } } }
Maintenant, nous pouvons appeler cette combinaison de mixins et de fonctions dans n'importe quel endroit qui nous convient:
.txt { @include emFonts($text-size, 0) }
Et à la sortie, nous obtenons 4 classes pour du texte de différentes tailles:
.txt-m { font-size: 1.125em; } .txt-s { font-size: 1em; }
De même, des fonctions pour les tailles de titre, le texte et les couleurs de remplissage, les polices, etc., sont créées et appelées.
Autrement dit, le travail sur chaque projet commence par le remplissage des valeurs des variables, et les classes et les fonctions elles-mêmes migrent d'un projet à un autre.
Moteur de modèle.
Je pense que beaucoup d'entre vous utilisent les modèles, et il s'agit très probablement de Pug (anciennement appelé Jade).
Pour la composition atomique, c'est nécessaire grâce à 3 choses:
- mixins
- les variables
- cycles
Pug nous sauve complètement des microclasses encombrantes de code HTML, car nous pouvons transformer le code suivant:
… <ul class=”menu__list flex-ai-center w-100 relative “> <li class=”menu__item m-color m-font txt-s inline-block bold-border”>first</li> <li class=”menu__item m-color m-font txt-s inline-block bold-border”>second</li> <li class=”menu__item m-color m-font txt-s inline-block bold-border”>third</li> </ul>
pratique pour l'édition:
-let menuItemClasses = 'menu__item m-color m-font txt-s inline-block bold-border' // ul li(class=`${menuItemCLasses}`) frst li(class=`${menuItemCLasses}`) second li(class=`${menuItemCLasses}`) third ... </ul>
ou dans un autre mode de réalisation, en utilisant une boucle:
let menuItems = ['first', 'second', 'third'] ul -for(let item of menuItems) { li(class=”menu__item m-color m-font txt-s inline-block bold-border”) -}
Ceci n'est pas moins pratique, car la ligne avec les classes nécessaires n'est pas répétée plus d'une fois.
La dernière vulnérabilité de cette méthodologie était qu'un grand nombre de classes inutilisées restaient dans le code. Mais ce problème apparemment grave a été facilement résolu en ajoutant des plugins au générateur de projet qui suppriment les classes inutiles.
Conclusion
En conclusion, je voudrais dire ce qui suit:
Avant de commencer à utiliser la «méthodologie presque atomique», j'ai longtemps utilisé smacss puis BEM. Par conséquent, à partir de bem, je n'ai laissé que les noms des classes nécessitant des descriptions des retraits et des tailles, ainsi que la hiérarchie de stockage des fichiers et des dossiers. Un ensemble de classes et de fonctions toutes faites, je me connecte au projet en tant que bibliothèque.
Un point important que je voudrais noter est la commodité de la mise en page des pages et de ses sections individuelles dans leur ensemble. Grâce aux microclasses, il est assez facile de créer un "squelette" d'une page ou d'une section dans le moteur de modèle et ensuite de continuer à écrire des styles pour celui-ci.