本日这篇重要讲讲 Ember CLI 里关于款式开辟的一些前期预备事情，重假如 Sass 和 Bootstrap。

Ember Addons 是寻觅种种组件的绝佳场合，下文将要引见的一些都能够在这里找到，没事的时刻多探究一下会有很多欣喜。

关于 Sass

Sass 的演化和运用在前端开辟领域真是个又臭又长的话题，假如你是自行搭建构建体系你就邃晓我说的意义了。还好 Ember CLI 的生态体系比较完整，也有一个宽大的社区做后援可以为我们省去很多工夫。

关于 Sass 的基本运用，我们只须要装置 | 3822741913b0abccece813de6916a2f41 | 就好了，它默许运用 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

前面提到了用 | 3822741913b0abccece813de6916a2f415 | 来援用 Bootstrap 的要领，不过在 Ember CLI 项目里，我照样引荐你用 ember-cli-bootstrap-sassy 来辅佐你做这件事，因为这个 addon 分外做了几件功德：

1. 增添了 bower 版的 bootstrap-sass，省去了你人工寻觅和装置的历程

2. 完成了 includePaths 的设置，以免你忘记了

3. 完成了 | 3822741913b0abccece813de6916a2f420 | 和 剧本文件的导入，好费心呐

4. Bootstrap 自带的字体图标能够挑选不导入，JavaScript 的模块能够挑选性的导入也许完整不要，详细设置以下所示：

var app = new EmberApp(defaults, {
    // ...
    'ember-cli-bootstrap-sassy': {
        glyphicons: false,
        js: ['transition', 'collapse']
    }
})

运用／定制 Bootstrap 的准确姿态

关于这个话题我几乎能够写本小说出来了，在我带实习生的历程里被问到和发明最多题目的就是 Bootstrap 的用法，限于篇幅我在这里只将一些前期的要点：

别直接用 _bootstrap.scss

大多数人是如许用的：直接在主款式文件里 @import "bootstrap";，然后碰到须要定制的就最先掩盖掩盖掩盖……别这么搞！

看一下 | 3822741913b0abccece813de6916a2f424 | 以及 源码 便晓得人家原本就是模块化开辟的，既然用了 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 里也很简朴，| 3822741913b0abccece813de6916a2f436 |，然后设定一下 | 3822741913b0abccece813de6916a2f437 | 就好，异常轻量，异常好用

Bourbon

Bootstrap 本身定义了一些 | 3822741913b0abccece813de6916a2f439 | 善用它们会令你事半功倍，但是习气了 compass 的开辟者也许照样会以为不够用吧？因而我向你引荐 Bourbon，ThoughtBot 出品，Ruby 社区应当不生疏的，质量一流。

总的来说 Compass 就不要再用了，又大又笨而且连亲爹都预备摒弃它了，将来将是小快灵组件协同事情的大趋势，Bourbon 就是能够用来替换 | 3822741913b0abccece813de6916a2f441 | 的组件库。别的它的兄弟 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 先从路由最先。

原文首发于 Ruby China 社区，转载请说明。