ホームページ » コーディング » 開発者のためのSassベストプラクティスのヒントとツール

    開発者のためのSassベストプラクティスのヒントとツール

    jQueryがどのようにして一般的なJavaScriptに革命を起こしたかのように, SassはバニラCSSに革命をもたらしました. Sassを学ぶほとんどの開発者は、彼らが決して戻りたくないということに同意します。多くの人はまた、新しい開発者にとっての最大の問題は 方法 彼らはSassそれ自体ではなくSassを使います.

    私はウェブを精査し、この記事をまとめました 拡張可能で再利用可能なSassコードを書くためのベストプラクティス. 提案は私自身の意見やSass Guidelinesのような信頼できるウェブサイトからのものです。.

    あなたは確かにあなたのワークフローにこれらすべての機能を実装する必要はありません。しかし、少なくともこれらのアイデアを楽しませ、潜在的な利点を熟考することは価値があります。.

    ファイル編成

    Sass開発から始めるのに最適な場所はファイル編成です。すでにモジュラーコードを使っているのであれば、インポートとパーシャルの価値を理解する必要があります(これらについては後で詳しく説明します)。.

    しかし今のところDoCSSaのこのファイル構造の例を見てください。私はあなたが以下で見ることができるこのファイル構造を作り直しました:

    これは単なる提案であり、ファイルを整理する方法の1つです。あなたはのような異なるフォルダ構造を使用する他の方法を見つけることができます “グローバル” サイト全体のSCSSの場合 “ページ数” ページ固有のSCSSの場合.

    各フォルダの目的を調べるために、この提案された編成スタイルを見ていきましょう。

    • / globals - 文字体裁、色、グリッドなど、サイト全体に適用されるSassファイルが含まれています。
    • /コンポーネント - ボタン、テーブル、入力フィールドなどのコンポーネントスタイルを持つSassファイルが含まれています。
    • / section - 特定のページまたはページ上の領域専用のSassファイルが含まれています(/ components /フォルダーに統合してうまく機能する可能性があります)。
    • / utils - Bowerのようなツールで動的に更新できるNormalizeのようなサードパーティのユーティリティが含まれています.
    • main.scss - 他のすべてをインポートするルートフォルダ内のプライマリSassファイル.

    これは基本的な出発点にすぎません。独自のアイデアで拡張する余地は十分にあります。.

    しかし、どのようにあなたがあなたのSCSSを組織化することを選択したとしても、それはあなたが重要です。 何らかの組織がある Normalizeのように更新が必要なライブラリ用の別のファイル(またはフォルダ)と、プロジェクト用のSassパーシャルのコンポーネント.

    セスパーシャルは現代のベストプラクティスに不可欠です。これらはZurbのデザインチームや他の多くのプロのフロントエンド開発者によって強く推奨されています。.

    これがSassのWebサイトからのパーシャルの説明です。

    “他のSassファイルに含めることができるCSSの小さな断片を含む部分的なSassファイルを作成できます。これは素晴らしい方法です。 CSSをモジュール化し、物事を維持しやすくする. パーシャルは、先頭にアンダースコアを付けたSassファイルです。あなたはそれを次のような名前にするかもしれません _partial.scss. アンダースコアはSassにそのファイルが部分的なファイルでありCSSファイルに生成されるべきではないことを知らせます。 Sassパーシャルは @インポート 指令.”

    Sassファイル構造に関する他の記事もご覧ください。

    • Sassプロジェクトをどのように構成するか
    • 美的Sass:建築および様式の構成
    • コード管理に役立つディレクトリ構造

    輸入戦略

    Sassのインポートとパーシャルの価値について十分とは言えません。コード構成は、インポート構造とワークフローをうまく機能させるための鍵です。.

    開始するのに最適な場所は、インポート、変数、ミックスインをまとめたグローバルシートです。多くの開発者は変数とミックスインを分離することを好みますが、これは意味論に帰着します.

    ミックスインは Sassコードをインポートする、または複製する方法. 彼らは信じられないほど強力ですが、一緒に使うべきではありません “静的” コード。ミックスイン、エクステンド、プレースホルダーの間に違いがあることを覚えておいてください。これらはすべてSass開発で使用されています.

    ミックスインは、コードを変更するためにミックスインに渡される動的な値で最もよく使用されます。たとえば、2色の間に背景のグラデーションを作成するこのSassミックスインを調べてください。.

    @mixin linearGradient($ top、$ bottom)背景:$ top; / *古いブラウザ* / background:-moz-linear-gradient(上、$ top 0%、$ bottom 100%); / * FF3.6 + * / background:-webkit-gradient(線形、左上、左下、カラーストップ(0%、$ top)、カラーストップ(100%、$ bottom))。 / * Chrome、Safari4 + * / background:-webkit-linear-gradient(上、$ top 0%、$ bottom 100%); / * Chrome10 +、Safari5.1 + * / background:-o-linear-gradient(上、$ top 0%、$ bottom 100%); / * Opera 11.10以降* / background:-ms-linear-gradient(上、$ top 0%、$ bottom 100%); / * IE10 + * / background:線形グラデーション(一番下まで、$ top 0%、$ bottom 100%)。 / * W3C * / filter:progid:DXImageTransform.Microsoft.gradient(startColorstr = "#ffffff"、endColorstr = "#000000"、GradientType = 0); / * IE6-9 * /

    ミックスインは2つの値を取ります。上の色と下の色です。 3色または4色以上の色を含むグラデーションの種類ごとに、異なるmixinを作成できます。これにより、カスタムオプションのパラメータを変更しながらミックスインコードをインポートおよび複製することができます。.

    Code Responsibleの例は次のようになります。

    .button @include linearGradient(#cccccc、#666666); 

    mixinに関連しているのはSassのプレースホルダーで、これは主にextendディレクティブで役に立ちます。ミックスインよりも確かに複雑ですが、これは 余分なコードを書き直さずにセレクタを結合する.

    Sassには@importメソッドが1つしかありませんが、1つのファイルに記述できるがどこにでも含めることができるコードの柔軟性を示すために、ミックスインとプレースホルダーを含めました。.

    インポート構造を構築する際には、DRYコーディングの概念に従うことを忘れないでください(自分で繰り返さないでください)。.

    命名規則

    命名規則の一般規則は、変数、関数、およびミックスインに適用されます。 Sassで何か名前を付けるときには 区切り文字にはすべて小文字のダッシュを使用する.

    上記のコード構文は実際にはCSSガイドラインのルールセットに基づいています。ここで留意すべきいくつかの推奨されるベストプラクティスは次のとおりです。

    • 2つのスペースインデント、タブなし
    • 理想的には、80文字以下の行数
    • 空白の意味のある使い方
    • コメントを使ってCSSの操作を説明する

    これらは有効なSassコードの必須項目ではありません。しかし、これらの提案はプロの開発者からのものです。 これらのルールセットが最も均一なコーディング経験を提供することを発見しました.

    しかし、命名規則に関しては、Sass名用とCSSクラス名用の2つの異なる構造になる可能性があります。何人かの開発者はSass提案よりBEMを好む。どちらも正しいとは限りません。操作手順が違うだけで違います.

    問題は、BEMがSassの変数やミックスインにうまく引き継がないことです。なぜなら、それらはブロック/要素/修飾子(BEM)構造を持っていないからです。私は個人的にはSassの命名規則を使うことを好みますが、あなたはcamelCaseからあなた自身の内部構文まで何でも試すことができます.

    変数やミックスインを整理するときには それらをカテゴリ別に分割してからアルファベット順に並べる. どこにあるのかを正確に知っているので、これにより編集がずっと簡単になります。.

    たとえば、リンクの色を変更するには、変数ファイルを開きます(おそらく _variables.scss)と色変数のセクションを探します。次に名前でリンクを見つけ(ヘッダーリンク、テキストリンクなど)、色を更新します。単純な!

    Sassファイルの目次をどのように構成するのかを知るためには、Foundationの設定ファイルを調べてください。.

     //サイト設定の基礎// ----------------------------- // //目次:// // 1 。Global // 2. Breakpoints // 3. The Grid // 4. Base Typography // 5. Typography Helpers…// 1. Global // --------- $ global-font-size:100 %; $ global-width:rem-calc(1200); $ global-lineheight:1.5。 //など

    別の命名法はに関連しています レスポンシブブレークポイント. Sassブレークポイントに名前を付けるときは、デバイス固有の名前を避けてください。小さい、med、lg、xlgのような名前を書くのが良いでしょう。 互いに対して.

    これはブレークポイント間の内部関係には向いていますが、開発者がどのデバイスが互いに関連しているのかわからないチームには最適です。.

    実際に名前をつけるのは、あなたにおすすめです。 余分な変数を使わずにできるだけ具体的にする. あなたがすべき 覚えやすいサイト全体の命名規則を採用する コーディング中.

    色、余白、フォントスタック、行の高さなど、すべてに固有の命名規則を付けます。名前がすぐに思い出せるだけでなく、 既存の構文と一致する必要がある新しい変数名を書くときあなたの仕事をより簡単にします.

    しかし、あります 特異性と畳み込みの間の細かい関係. 練習はあなたがその行を見つけるのを助けます、そしてより記憶に残る名前を書くことは他のプロジェクトにコードをコピーすることをより簡単にします.

    ネスティングとループ

    これら2つのSassテクニックはアクションが大きく異なりますが、どちらも 慎重に使用されていない場合に悪用される可能性.

    ネスティング のプロセスです より少ないコードでより具体的にするために、インデントを通してネストしたセレクタを追加する. Sassには、実際のコードのネストの例を示すネストガイドがあります。しかし、入れ子にするのは簡単です。あなたが熱心であるならば、あなたはこのように見えるコードで終わることができます:

    body div.content div.container … body div.content div.container div.articles … body div.content div.container div.articles> div.post … 

    このタイプのコードは、あまりにも具体的すぎて上書きすることはほとんど不可能です。スタイルシートをカスケードすることの目的は無効になります。.

    このSitePointガイドを読み飛ばすと、ネストのための3つの黄金律が見つかります。

    • 決して3レベルを超えない.
    • CSS出力がクリーンで再利用可能であることを確認してください.
    • デフォルトのオプションとしてではなく、意味がある場合は入れ子を使用する.

    開発者Josh Brotonは必要に応じてネスティングを提案し、残りは一般的な構文規則としてインデントします.

    セレクタをインデントしても、カスケードCSS効果は発生しません。しかし、どのクラスが互いに関連しているのかを正確に突き止めることで、Sassファイルを簡単にスキムすることができます。.

    ループもできます 適切に適用されていない場合は使いすぎになる. 3つのSassループは @にとって, @ while, そして @各. これらがすべてどのように機能するのかについては詳しく説明しませんが、興味があるならこの記事をチェックしてください。.

    代わりに、私はカバーしたいのですが ループを使用する目的 そしてそれらがSassでどのように機能するのか。自動化できるコードを書く時間を節約するためにこれらを使うべきです。例えば、これはClubmate投稿のコードの一部で、Sassコードとそれに続く出力が示されています。

    / * Sassコード* / @ 1〜8の$ i $ width:パーセンテージ(1 / $ i).col  - #$ i width:$ width;  * / * output * / .col-1 幅:100%; .col-2 幅:50%; .col-3 幅:33.333%; .col-4 幅:25%;  .col-5 幅:20%; .col-6 幅:16.666%; .col-7 幅:14.285%; .col-8 幅:12.5%;

    これらの列クラスはグリッドシステムと組み合わせて使用​​できます。ループコードを編集するだけで、さらに列を追加したり、列を削除したりできます。.

    ループ すべき ではない セレクタのセレクタまたはプロパティを複製するために使用されます。;それがmixinの目的です.

    また、ループするときに、データのキーと値のペアを格納するSassマップと呼ばれるものがあります。上級ユーザーは可能な限りこれらを利用するべきです.

    しかし、通常のSassループは繰り返しなくコード出力を提供するのにシンプルで効果的です。ループを使う一番の理由は データ出力を変えるCSSプロパティ.

    これがあなたのループが役に立つかどうかをチェックする良い方法です:あなた自身に尋ねてください CSSを出力する他の方法があれば、必要なコード行数を減らすことができます。. そうでなければ、ループの構文はおそらく素晴らしいアイデアです。.

    混乱したり、ネストやSassループについてのフィードバックが必要な場合は、/ r / sass /または/ r / css /のいずれかに質問を投稿してください。.

    モジュール化

    モジュラーSassを書く習慣はほとんどのプロジェクトにとって絶対に必要です(私は主張しますが、すべてのプロジェクト)。モジュール化は プロジェクトを小さなモジュールに分割する. これはSassで次のようにして実現できます。 パーシャル.

    モジュラーSassの背後にある考え方は、グローバルコンテンツ(タイポグラフィ、グリッド)またはページ要素(タブ、フォーム)をターゲットとする特定の目的で個々のSCSSファイルを書くことです。.

    Sassモジュールの定義はかなり明確で、非常に具体的な提案をしています。 モジュールをインポートしてもコードは出力されません.

    すべてのモジュールに対して強制的な出力を行うという考えは、最適化にとって悪夢となります。代わりに、モジュールを個別に作成してください。 必要なものだけを呼び出す. モジュールはミックスインや関数で定義できますが、セレクタを含むモジュールを作成することも可能です。.

    しかし、Sass Wayの記事では、すべてのセレクターをミックスインとして記述し、必要に応じてそれらを呼び出すだけであることを提案しています。これを採用するかどうかは、最終的にはあなたの選択です。私はそれがプロジェクトのサイズとミックスインの取り扱いに対するあなたの快適さにかかっていると思います.

    The Sass Wayに関する投稿からのJohn Longの引用

    “私にとって、モジュールは私のSassプロジェクトの基本単位または構成要素になりました.”

    もしあなたが本当にSassルーチンを探しているなら、私は完全にモジュール化することをお勧めします。基本的なCSSファイルに含まれるモジュラーパーシャルとして、ほとんどすべてを構築してみてください。最初はこのワークフローは面倒なように思えるかもしれませんが、特に大規模プロジェクトでは、より壮大な規模では意味があります。.

    さらに、モジュールが別々のファイルに配置されている場合は、プロジェクト間でモジュールをコピーする方がはるかに簡単です。. 柔軟性 そして 再利用可能なコード モジュール開発の礎石.

    Sassモジュールとモジュール化手法の詳細については、以下の記事をご覧ください。

    • CSSモジュール:未来へようこそ
    • モジュラーセスの長所と短所
    • SMACSSとSASSを使用したモジュラーCSS編成

    あなたの完璧なワークフローを見つける

    各チームと個々の開発者は、最も効果的な独自のプラクティスを持っています。あなたは個人的にあなたにとって最も効果的なプラクティスを採用するか、プロとしてあなたのチームにとって最も効果的なプラクティスを採用することを選択するべきです。.

    プロジェクトの自動化にGulpまたはGruntを使用してコードを縮小することも検討してください。これにより多くの手作業を省くことができ、自動化ツールは間違いなく現代のフロントエンド開発のためのベストプラクティスの一部です。.

    GitHub上のFoundationのSCSSのようなオープンソースライブラリを調べて、他のライブラリで採用されているベストプラクティスの詳細を学んでください。.

    ベストプラクティスについての最も重要なことは、それらがあなたの仕事をほとんどの場合本当に改善するということですが、多くの選択肢があります。ただ物事を試して、それらがどのように感じるかを見てください。あなたは常に学んでいるので、あなたのベストプラクティスは5年間で急速に変わるかもしれません。.

    Sassプロセス全体についての最後の提案は、次のとおりです。 明確さを念頭に置いて決定を下す. 仕事を楽にするコードを書く. もっと簡単な方法があれば、プロジェクトを過度に複雑にしないでください。.

    SassはCSSの開発経験を向上させるためのものです。 明確かつベストプラクティスで作業する 最高の経験を可能にするために.

    要約

    Sassワークフローの輻輳は、コードスタイルを調整し、ベストプラクティスに従うことで修正できます。 Sassのブログとプロの開発者から寄せられたこの記事の中で、私は一握りの提案を概説しました。.

    さらに学ぶための最善の方法は、これらのプラクティスをワークフローに適用することです。 何がうまくいくのかを見る. 時間が経つにつれて、いくつかの活動は他の活動よりも有益であることがわかります。 うまくいくものは何でも保持し、そうでないものは削除する.

    Sass開発のためのより多くのヒントとベストプラクティスを見つけるためにこれらのリンクをチェックしてください:

    • セスガイドライン
    • 私たちの心のビジョン
    • Sassを最大限に活用するための8つのヒント
    • 混乱を招くことなくSassで拡張
    • Sassのベストプラクティス - 3レベル以上の深さのネスト