2014-06-06 3 views
2

Je suis dans les premières étapes d'un projet qui va amasser une très grande quantité de styles à mesure qu'il grandit. Nous discutons des mérites du modèle de mixage du préprocesseur CSS pour le séchage de notre code de style. Les avantages sont assez clairs lorsque le mixin est paramétré - presque chaque instance devrait être manuscrite de toute façon, et donc il y a relativement peu de bourrage de code, surtout si aucun paramétrage particulier n'est utilisé fréquemment. Cependant, pour les mixines non paramétrées, c'est un peu plus flou. Prenez clearfixing par exemple.Mixins de préprocesseur CSS par rapport aux classes de balisage

En CSS pur, nous ferions probablement une classe cf, puis l'invoquerons dans le balisage si nécessaire. Cela fonctionne bien, mais litows le balisage avec des classes purement de présentation.

En SASS, nous pourrions échapper à cela en utilisant un mixin pour ce faire:

//in _mixins.scss 
@mixin clear-fix() { 
    &:before, &:after { 
    content: '\0020'; 
    display: block; 
    clear: both; 
    visibility: hidden; 
    line-height: 0; 
    width: 0; 
    height: 0; 
    } 
} 

//in my_component.scss 
@import 'mixins'; 

.my_component { 
    // styles ... 
    @include clear-fix() 
} 

Ceci a l'avantage de centraliser les préoccupations purement et rendre notre présentation du code de style plus maintenable. Mais l'inconvénient est que le CSS compilé sera très unDRY, avec le mixin de clear-fix répété mot pour mot dans chaque bloc dans lequel il est mélangé (appliquez ceci à n'importe quel pattern CSS similaire que nous utilisons de la même manière). Ma question est de savoir si la répétition du code mélangé est susceptible de causer des problèmes majeurs? Ou y a-t-il une autre solution à laquelle je ne pense pas?

Répondre

2

Je pense que l'inconvénient majeur de l'exemple que vous avez donné est que vous vous répétez partout où vous utilisez un clearfix ... donc dans votre exemple, si vous avez 100 éléments qui utilisent la classe clear-fix, vous auriez 693 lignes supplémentaires de CSS qui ne sont pas nécessaires.

Deux suggestions:

  1. J'utiliser mixins seulement quand ils prennent des paramètres et les propriétés CSS changent réellement de la valeur. L'utilisation de mixins "void" semble inefficace car vous pouvez simplement utiliser simplement du vieux CSS.
  2. Vérifiez le CSS orienté objet de stubbornella ici: https://github.com/stubbornella/oocss/wiki. Si vous abstrait votre clear-fix mixin dans un objet CSS réutilisable, vous êtes beaucoup plus sec (si tu serais encore vous répéter un peu)
+0

Sons comme un gagnant-gagnant. La clé étant d'identifier le petit nombre de modèles abstraits réels, qui requièrent un «clear-fix» comme détail. Ensuite, les classes utilisées restent significatives sur le plan sémantique et 'clear-fix' peut être défini une seule fois comme un mixin still, mais répété un nombre limité de fois. – acjay

0

Votre autre option est d'utiliser extend. Ce serait une approche DRYer plutôt que de réutiliser un mixage tout le temps car elle sépare les sélecteurs plutôt que de dupliquer les styles.

Exemple

.bacon {  
    color: red; 
} 

.smokey { 
    @extend .bacon; 
} 

// Outputs 
.bacon, .smokey { 
    color: red; 
} 

http://css-tricks.com/the-extend-concept/

+0

Merci de me rappeler de 'extend'. Bien que je sois resté avec le même flux de travail en haut, au lieu d'avoir des douzaines de sélecteurs séparés contenant le même code de correction claire, j'aurais un sélecteur avec des douzaines de cas séparés par des virgules. Il me semble que ce serait encore un problème de performance possible. – acjay

Questions connexes