EmberJS [Tips on Ember 2] Ember CLI 和 Sass (及其周边) 的协同工作

nightire · 2015年09月09日 · 最后由 wppurking 回复于 2015年09月11日 · 10153 次阅读

今天这篇主要讲讲 Ember CLI 里关于样式开发的一些前期准备工作,主要是 Sass 和 Bootstrap。

Ember Addons 是寻找各种组件的绝佳场所,下文将要介绍的一些都可以在这里找到,没事的时候多探索一下会有很多惊喜。

关于 Sass

Sass 的演变和使用在前端开发领域真是个又臭又长的话题,如果你是自行搭建构建系统你就明白我说的意思了。还好 Ember CLI 的生态系统比较完备,也有一个广大的社区做后盾可以为我们省去很多功夫。

对于 Sass 的基础使用,我们只需要安装 ember-cli-sass 就好了,它默认使用 node-sass,支持 SourceMaps 和 IncludePaths 等功能选项,比较省心。较新的 Ember CLI 应该是直接内置了 ember-cli-sass 的,推荐升级哦。

对于不太熟悉 Sass 的程序员,IncludePaths 值得一讲,我见到有些人啊为了方便的 import,把许多第三方的 sass 文件拷过来拷过去的,其实大可不必哦~就拿 bootstrap-sass 为例好了:

安装 bootstrap-sass:

$ npm install bootstrap-sass --save

完后呢,入口文件的路径在 node_modules/bootstrap-sass/assets/stylesheets 这里,因为通常 node_modules/bower_components/ 这些目录是不会被包含在项目里的(包含在 Git 或 HTTP Server Root 下),所以才会有手工拷贝到别处的做法。在 Ember CLI 里,你可以这样设置一下:

// ember-cli-build.js or Brocfile.js
var app = new EmberApp(defaults, {
    sassOptions: {
        includePaths: [
            'node_modules/bootstrap-sass/assets/stylesheets'
        ]
    }
})

之后在项目的 sass 文件内直接 @import "bootstrap"; 就好了,那是一个数组所以你懂的,你可以设置很多路径,sass 在编译的时候会挨个儿去找。

关于 POD

如果你跟我一样喜欢 POD 文件结构,那么还有一个 ember-cli-sass-pods 也可以用用,这个东西能让你这样生成 sass 文件:

$ ember generate style [name] -p

生成的文件会保存在同名的 POD 目录下,不过我一向都是手动创建文件的,所以并没有实际测试它。对于样式文件在 POD 架构下的导入我是这样做的:

  1. 创建 app/styles/_pods.scss 文件
  2. app/styles/app.scss 文件里添加一句 @import "pods";
  3. includePaths 那里添加 app/pods 这一项
  4. 新增加的 PODs 样式在 app/styles/_pods.scss 内这样引用:`@import "name/style;"

后来我注意到 ember-cli-sass-pods 也是这么做的,英雄所见略同嘛~

关于 Bootstrap w/ sass

前面提到了用 includePaths 来引用 Bootstrap 的方法,不过在 Ember CLI 项目里,我还是推荐你用 ember-cli-bootstrap-sassy 来辅助你做这件事,因为这个 addon 额外做了几件好事:

  1. 添加了 bower 版的 bootstrap-sass,省去了你人工寻找和安装的过程
  2. 完成了 includePaths 的设置,免得你忘记了
  3. 完成了 字体文件的导入脚本文件的导入,好省心呐
  4. Bootstrap 自带的字体图标可以选择不导入,JavaScript 的模块可以选择性的导入或者完全不要,具体设置如下所示:
var app = new EmberApp(defaults, {
    // ...
    'ember-cli-bootstrap-sassy': {
        glyphicons: false,
        js: ['transition', 'collapse']
    }
})

使用/定制 Bootstrap 的正确姿势

关于这个话题我简直可以写本小说出来了,在我带实习生的过程里被问到和发现最多问题的就是 Bootstrap 的用法,限于篇幅我在这里只将一些前期的要点:

别直接用 _bootstrap.scss

大多数人是这样用的:直接在主样式文件里 @import "bootstrap";,然后遇到需要定制的就开始覆盖覆盖覆盖……别这么搞!

看一下 Bootstrap Sass 的目录结构 以及 源码 便知道人家本来就是模块化开发的,既然用了 sass 咱就应该把它当成级别高点的编程语言来对待。我是这么做的:

  1. 创建 app/styles/_custom-bootstrap.scss 文件
  2. app/styles/app.scss@import "custom-bootstrap";,一般来说这个应该是第一个导入的模块
_custom-bootstrap.scss 怎么用?

一开始你可以把原来的 _bootstrap.scss 内容原封不动拷贝进来,由于 includePaths 的作用,所有导入的路径都可以不变。

然后把所有的模块导入都注释掉,此时你的项目里等于完全没有 Bootstrap。

之后一般会分两种情况来定制:

  • 需要用到且可以直接沿用的模块

这个简单,把注释的部分去掉就好了嘛。曾经有徒弟质疑我:“师傅,人家官网上有自定义模块构建的功能,咱为啥不用那个?”

图样图森破,那个功能就是拿来秀的,一点实用性都没有。有多少人自定义构建之后从头用到尾刚刚好既不多又不少的?神都预测不到你会用到哪些组件的,难道你一遍又一遍的去构建定制版本啊?那是菜鸟的用法。

  • 需要用到但得修改/定制的模块

这里又可以大致分出两种情形,比较简单的改动——比如变量,你可以把其定义写在 @import "bootstrap/variables"; 的前面(特别是覆盖默认变量的,一定注意顺序);我会做的比较彻底,直接创建一个 app/styles/_custom-variables.scss 并且作为第一个模块导入进去。另外,自定义的变量不需要写尾部的 !default

第二种情形就比较进阶一些了,我举个例子,以前经常看见这样的写法:

<button type="button" class="btn btn-default btn-block btn-purple">...</button>

我说你写这么多 class 不累啊?人家 Bootstrap 是为了可重用性才定义了这种粒度很细的 helper classes,如果你是做一个 rapid prototype 那我没意见,但是正式的产品这样写问题就大了:

  1. btn-purple 这样的命名是很糟糕的,完全没有语义性,万一将来要换个色彩主题怎么办?可维护性也很差,万一将来维护的是个色盲怎么办?(开个玩笑)
  2. 重复的写一串 class 可读性也很差,如果将来要进行微调,不熟悉这些 class 的人会被折腾死

该怎么写?

<button type="button" class="button-main button-block">...</button>
/// app/styles/_custom-buttons.scss

// Overwrite for more semantic button class names
.button {
    @extend .btn;

    // Bootstrap doesn't give buttons transition effects by default,
    // so we simply extend it here. You can use some mixin instead.
    transition: all .2s ease-out;
}

@each $name in default, primary, success, warning, danger, info, block {
    .button-#{$name} {
        @extend .btn-#{$name};
    }
}

// Define site-wide main button colors
$button-main-color:  #fff;
$button-main-bg:     $violet;
$button-main-border: darken($violet, 5%);

.button-main {
    @extend .button;
    @include button-variant(
        $button-main-color, $button-main-bg, $button-main-border
    );
}

这是个例子,我从最近的一个项目里扒出来的,仅就这一例子而言或许有点小题大做,但如果考虑一个大型的项目,这样的改造绝对是有必要的。好的习惯要从小养成,正确的姿势得贯彻始终。

类似的技巧还有好多,鉴于这里的主题是 Ember CLI 呢便就此打住了,我也是想:既然选择了 Ember 这么靠谱的前端框架,相应的前端技术也应该靠谱起来吧,所以抛砖引玉一下。

还有什么值得一用?

Bootstrap 绝对不完美,只会用它的前端工程师绝对不是合格的前端工程师,针对 Bootstrap 不完善的地方 sass 社区还有非常多的组件值得一用。在这里我先推荐几个,以后还可以再补充。

Susy

Bootstrap 的 Grid 系统很一般(虽说对它的定位而言也够用),定死的 12 栅格并非时时够用;嵌套时的 gutter 无法灵活调整;需要手动覆盖 row 两端 cols 的 padding(当你需要边缘与 container 对齐的时候,如 gallery 布局)……等等槽点都被喷了好几年了。

Bootstrap v4 将使用 flex 做 Grid 系统,这是好事

所以我推荐你试一下 Susy,做布局——专业的!用在 Ember CLI 里也很简单,npm install susy --save,然后设定一下 includePaths 就好,非常轻量,非常好用

Bourbon

Bootstrap 自己定义了一些 mixins 善用它们会令你事半功倍,然而习惯了 compass 的开发者大概还是会觉得不够用吧?因此我向你推荐 Bourbon,ThoughtBot 出品,Ruby 社区应该不陌生的,品质一流。

总的来说 Compass 就不要再用了,又大又笨而且连亲爹都准备放弃它了,未来将是小快灵组件协同工作的大趋势,Bourbon 就是可以用来替代 compass/css3 的组件库。另外它的兄弟 Neat 也不错,只是功能上和我们上述的工具集合有冲突了,不是很有必要。

Breakpoint

这个推荐一下,可以选用,主要是用来辅助响应式设计开发的,比 Bootstrap 自带的那点特性强大多了。http://breakpoint-sass.com/

关于后期处理

前面说的一大堆综合起来都是做 CSS 的前期处理的(也就是 pre-processing),现在前端也很重视后期处理(post-processing),关于这个话题呢推荐看一下 pleeease 也就差不多了。

样式的后期处理有很多范畴,综合考虑我认为目前唯一称得上必须要做的那就是 Autoprefixer,这个东西的特点及用法概括如下:

  1. 有了它,你再也不用去写 vendor prefixes,连想都不要去想(如果你用到的第三方组件越俎代庖了也没关系,Autoprefixer 会自动筛选一遍)
  2. 当你构建的时候,它会自动分析你的样式,然后添加必要的 vendor prefixes
  3. 你可以指定针对的浏览器品牌,版本,受众地区等等参量,从而让它知道哪些 vendor prefixes 是需要加的
  4. 它通过 Can I Use 提供的技术数据来完成最终的工作

ember-cli-autoprefixer 可以帮助你把它集成到 Ember CLI 项目中,简单好用。以下是一个配置的范例代码:

var app = new EmberApp(defaults, {
    // ...
    autoprefixer: {
        browsers: ['> 5% in CN', 'last 2 versions']
    }
})

仔细阅读一下 Autoprefixer 的文档,你会发现配置它所用到的 DSL(BrowserList) 还蛮有趣的。


得,今天就说到这里,本来这篇早就写得差不多了,只是这两天一直在挖/填 Ember2 的一些坑没顾上整理,耽误了。到此前期的周边打造就差不多了,下篇开始我打算重点写一些和 Ember 的特性密切相关的东东,maybe 先从路由开始。

感谢分享,ember 没体验过,sass 的部分很棒。👏

Bootstrap 的 Grid 系统很一般(虽说对它的定位而言也够用),定死的 16 栅格并非时时够用

Bootstrap 是 12 栅格吧

#1 楼 @etnl 嗯,是的,我写完没检查……

通过 ember-cli 来使用 sass 以及 sass 相关的工具真的是非常方便。ember-cli 中的将这些固定流程性的东西都整理到一起了. 引入 bootstrap 的场景问题,看来大家都会碰到哈。

外部资源的默认规则

在这个规则下我们可以通过 bower 将那些打包的前端用到的库管理到本地,然后使用 ember-cli-build.js 中或者代码中有选择引入构建的 dist/ 的目录中。

  • 静态引入的 app.import(xxx)
  • 动态引入的 sass @import 指令

区分 bower 与 npm 的使用

这个还是需要的,不过这两个同时存在 ember-cli 里面总会冒出一些模棱两可的地方 (功能重叠), 例如 bootstrap-sass 即可在 bower.js 中存在也可以在 package.json 中存在。但总体上来区分的话,既有 js 又有 css 的用 bower, 纯 js 以及要用到 node 的用 npm.

综合使用

在这两者的使用上,就可以整体上这么用。

  1. 通过 bower 和 npm 管理你的依赖 (外加自己的 vendor 文件夹)
  2. 默认规则 + 使用 app.import + sass @import 引入。

@nightire 我就是想找一个简化的 Compass 的 sass 工具集,我孤陋寡闻了,在这发现 bourbon 实在是我想的~~

另外请问一下,bourbon 中的那些 transition(xxx) 的 function 处理了多浏览器的 prefix 问题,那 Autoprefixer 的优势还会有哪一些呢?

#4 楼 @wppurking

bower 和 npm 的问题

其实现在整个前端都倾向于只要一个 npm 就好,但是当初 npm 自身有一些问题一直没有得到很好的解决,所以 bower 等就有了生存空间。现在已经是这个现状了,大家也很无奈,只好一点点的迁移吧,相信有一天包管理器会统一,ember cli 也只是顺势而为罢了。

bourbon 的问题

我不推荐沿用 bourbon 的 vender prefix,因为相比 autoprefixer(每次 build 的时候即时更新),bourbon 的更新毕竟是慢的,而且它的前缀写成什么样就什么样,错了漏了多余了你这个使用者也无可奈何(除非提交 pr 改它)。然而这也没办法,当初 bourbon 诞生的时候还没有 post-css,它也没料到会有 autoprefixer 这样的东西,而且也没法保证大家都知道用 autoprefixer。

至于 autoprefixer 的优势……难道你只用 bourbon 啊?你自己也要写啊,你还用其他的库啊,你没法保证大家都乖乖写好吧?autoprefixer 是针对最终 css 产生作用的,它的好处就是让你无脑写样式,从此不用考虑前缀写不写写多少的问题。

不过!它不能替代页面测试,因为供应商前缀不是万能的,不是说用了它所有的 css 在所有浏览器里都没有问题了,最终的测试还是必要的,它只是帮你省去了开发时的痛苦而已。

@nightire Got it. post-css 的处理面比 pre-processing 大好多....

如果是 prefix 的问题还是 autoprefixer 来得爽哉~

Thanks~

需要 登录 后方可回复, 如果你还没有账号请 注册新账号