ホームページ > 記事 > ウェブフロントエンド > [Ember 2 に関するヒント] Ember CLI と Sass (およびその周辺環境) の連携_html/css_WEB-ITnose
[Ember 2 に関するヒント] Ember CLI と Sass (およびその周辺環境) の連携_html/css_WEB-ITnose
- WBOYオリジナル
- 2016-06-21 09:06:581079ブラウズ
今日の記事は主に、Ember CLI、主に Sass と Bootstrap でのスタイル開発のためのいくつかの事前準備について説明します。
Ember アドオンは、さまざまなコンポーネントを見つけるのに最適な場所です。以下に紹介するコンポーネントの一部は、ここで見つけることができます。何もすることがない場合は、さらに探索すると、たくさんの驚きが見つかるでしょう。
Sass について
Sass の進化と使用は、フロントエンド開発の分野では非常に長くて臭いトピックです。独自のビルド システムを構築すれば、私の言っている意味が理解できるでしょう。幸いなことに、Ember CLI のエコシステムは比較的完全であり、その背後には広大なコミュニティがあるため、多くの労力を節約できます。
Sass の基本的な使用には、 | 3822741913b0abccece813de6916a2f41 | をインストールするだけで済みます。デフォルトでは、node-sass が使用され、SourceMaps や IncludePaths などの機能オプションがサポートされています。新しい Ember CLI には ember-cli-sass が直接組み込まれている必要があります。アップグレードすることをお勧めします。
Sass に詳しくないプログラマーにとって、IncludePaths については、簡単にインポートするために多くのサードパーティの Sass ファイルをコピーする人がいるのを見たことがありますが、実際には、その必要はありません。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.jsvar app = new EmberApp(defaults, { sassOptions: { includePaths: [ 'node_modules/bootstrap-sass/assets/stylesheets' ] }}) 次に、プロジェクトの sass ファイルに直接 @import "bootstrap"; これは配列なので、sass がコンパイルしています。一つ一つ探していきます。
POD について
私と同じように POD ファイル構造が気に入っている場合は、次のような Sass ファイルを生成できる ember-cli-sass-pods もあります。
$ ember generate style [name] -p生成されたファイルは次のようになります。 POD ディレクトリに同じ名前で保存されますが、私はいつも手動でファイルを作成するため、実際にはテストしていません。これは、POD アーキテクチャでスタイル ファイルをインポートする方法です:
を追加します
sass を使用した Bootstrap について
前に述べたように、Bootstrap メソッドを参照するには | 3822741913b0abccece813de6916a2f415 を使用することをお勧めします。このアドオンはさらにいくつかの優れた機能を備えているため、これを行うには ember-cli-bootstrap-sassy を使用してください。bootstrap-sass の bower バージョンを追加し、手動での検索とインストールのプロセスを節約します
忘れないように includePaths の設定を完了しました
var app = new EmberApp(defaults, { // ... 'ember-cli-bootstrap-sassy': { glyphicons: false, js: ['transition', 'collapse'] }}) Bootstrap の正しい使用方法/カスタマイズ方法
このトピックについて小説を書くことができます インターンを指導しているときに、この質問が最もよくありました。そして発見されたのは、Bootstrap の使用法です。スペースの制限があるため、ここではいくつかの予備的なポイントのみを説明します:_bootstrap.scss を直接使用しないでください
ほとんどの人は次のように使用します: @import をメイン スタイル ファイルに直接追加します。 bootstrap"; そして、カスタマイズする必要があるものに遭遇したときに、カバー、カバー、カバーを開始します...それはやめてください。
| 3822741913b0abccece813de6916a2f424 | を見ると、sass が元々モジュール形式で開発されていることがわかります。これが私がやったことです:
app/styles/_custom-bootstrap.scss ファイルを作成します@import "custom-bootstrap" を app/styles/app.scss に作成します。一般的に、これが最初の方法です。インポートされたモジュール
次に、すべてのモジュールのインポートをコメントアウトします。現時点では、プロジェクトにはブートストラップがまったくありません。
その後、カスタマイズは一般に 2 つの状況に分けられます:
使用する必要があり、直接使用できるモジュール
-
これは簡単で、コメント部分を削除するだけです。ある弟子が私に「先生、公式サイトにモジュール構築をカスタマイズする機能があるのですが、それを使ってみませんか？」と質問したことがあります
图样图森破，那个功能就是拿来秀的，一点实用性都没有。有多少人自定义构建之后从头用到尾刚刚好既不多又不少的？神都预测不到你会用到哪些组件的，难道你一遍又一遍的去构建定制版本啊？那是菜鸟的用法。
需要用到但得修改／定制的模块
这里又可以大致分出两种情形，比较简单的改动??比如变量，你可以把其定义写在 @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 那我没意见，但是正式的产品这样写问题就大了：
像 btn-purple 这样的命名是很糟糕的，完全没有语义性，万一将来要换个色彩主题怎么办？可维护性也很差，万一将来维护的是个色盲怎么办？（开个玩笑）
重复的写一串 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，这个东西的特点及用法概括如下：
有了它，你再也不用去写 vendor prefixes，连想都不要去想（如果你用到的第三方组件越俎代庖了也没关系，Autoprefixer 会自动筛选一遍）
当你构建的时候，它会自动分析你的样式，然后添加必要的 vendor prefixes
你可以指定针对的浏览器品牌，版本，受众地区等等参量，从而让它知道哪些 vendor prefixes 是需要加的
它通过 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 社区，转载请注明。