w3ctech

开发中的“麻烦”

开发中有一类“麻烦”是必须按照某种规则(思路)写代码,这类麻烦是不能省的。

sass让css实现模块化开发,值得注意的是模块化并不是把一个大文件分拆成几个小文件而已。依赖上下文的小文件拆出去不旦不能复用反而有害。看个例子a.scss:

%mod { … }
.mod-foo {
  @extend %mod;
  //…省略100行
}
//…省略1000行

将复杂的.mod-foo拆出去,a变成:

@import "b";
%mod {…}
@include foo;
//…省略1000行

b.scss为:

@mixin foo {

  .mod-foo {
    @extend %mod;
     //…省略100行
  } 
}

此时b依赖%mod,外部环境必须有%mod,在依赖很多的情况下b实际上难以维护。若进一步把通用的部分拆成c.scss:

%mod {…}

问题是在a里引c还是在b里引c?a里引的好处是一次引用,下面的代码包括引用的模块都可以用。b里引的话,a里及其它地方用到c的地方还要引c,这时就显得“麻烦”。这种“麻烦”不能省。模块的依赖显式声明出来是很有必要的。

再看另外一个案例,其中用了一套开源的font icon - ionicons,用的时候:

<span class="ion-heart"></span>

开源库总是会带有自己的前缀,如“ion-”。考虑到以后更换,通用和业务最好隔离开(反向依赖),在自己的项目里这样,用自己的前缀:

<span class=“ic-heart"></span>

css是:

@import "../ionicons/ionicons”;
.ic-heart {
  @extend .ion-heart;
}

随便打开一些知名网站,通常会看到这样的html:

<div class="search-panel-fields search-hp-fields search-common-panel”>

…
</div>

层叠的class名非常影响阅读代码。无非为了省事复用一些规则,更好的写法是:

<div class="search-panel”>

…
</div>

css的写法也许会“麻烦”些,将search-panel-fields, search-hp-fields, search-common-pane的通用部分抽成%common-panel:


%common-fields{
  //...省略
} 
%common-panel {
  //...省略
}

.search-panel {
  @extend %common-panel;
  @extend %common-fields;
}
.search-common-pane {
  @extend %common-panel;
}
.search-hp-fields {
  @extend %common-fields;
}

开发中有些“麻烦”是不能省的。看似简单的代码,值得再进一步反思一下。

前端圈微信

扫码关注前端圈微信公众号

共收到2条回复

  • 很容易理解~

    回复此楼
  • 这就是使用sass的好处,如果只是简单的把css用sass写了一遍,就没多大意义了,值的反思,如何用sass写出更好的css,也是自身的一种突破!

    回复此楼