Enduring CSS 05

ファイル構成と命名規則

-- WIP --

プロジェクト組織

ウェブサイト/アプリケーションからモジュール部品を簡単に取り外すことができるようにするには、モジュールを構成するファイルを整理する方法を考える必要があります。

通常、Webのものを構築するときは、プロジェクト内のファイルを技術タイプ別に分割するのが一般的なパターンです。

この基本的なフォルダ構造を考えてみましょう。

my-project/

- html/

- js/

- css/

これらのフォルダのそれぞれに、関連ファイルに名前を付けることができます。例えば：

my-project/

- html/

- v2ShoppingCart.html

- js/

- v2ShoppingCart.js

- css/

- v2ShoppingCart.css

しかし、ある点を越えて、ファイルに関連する名前を与えても、各スタイルシート、ロジックファイル、およびテンプレートがどのように関連しているのかを判断することは困難です。CSSフォルダに80個以上のCSS部分があり、htmlフォルダに50個以上のテンプレートスタブがあるかもしれません。

ウェブサイトやアプリケーションの「表示」部分は、通常、バニラHTMLではなく、Ruby、PHP、.NET、JavaScriptなどの任意の数の異なるテクノロジーによって生成されることが現実であると認識しています。

それで、特定のクラスが使用されているテンプレートを見つけるために、テキストエディタで 'find'に頼ることがますます必要になります。逆も同様です。特定のモジュールテンプレートに必要なスタイルを含む部分を見つけるには、 'find'が必要です。

この構造は物事を実行不能にするだけでは効率的ではなく、通常、何がどうなっているのかを覚えておくために少し精神的な方向づけが必要です。

ECSSでは必須ではありませんが、技術タイプ別に整理するのではなく、ファイルを視覚的または論理的な要素で編成してグループ化することが一般的には望ましい方法です。だから、これの代わりに：

html/

- shopping-cart-template.html

- callouts-template.html

- products-template.html

js/

- shopping-cart-template.js

- callouts-template.js

- products-template.js

css/

- shopping-cart-template.css

- callouts-template.css

- products-template.css

私たちはこのようなものを目指しています：

shopping-cart-template/

- shopping-cart.html

- shopping-cart.css

- shopping-cart.js

callouts-template/

- callouts.html

- callouts.js

- callouts.css

products-template/

- products.html

- products.js

- products.css

一見、これは一見重要ではないように見えるかもしれませんが、それは重要な利点をもたらします。

各コンポーネントのコードは物理的に自己囲まれます。そして、私たちの永続的なプロジェクトでは、機能を変更する必要があるか、非推奨になっている場合、そのモジュールの関連するコード（スタイル、ビューロジック（HTML）、JS）を簡単に更新/削除できます。

意図的に「グローバル」なCSSを除いて、コンポーネントまたはモジュールのプレゼンテーションに関連するすべてのコードは、そのコンポーネントのHTML / JSと並んでいる部分に含める必要があります。

あなたはそれが気に入らないかもしれませんが、常にある程度グローバルなCSSが必要です。最低限、リセットやスタイルの正規化などがあります。

CSSとアプリケーションロジック（JS / PHP / Rubyなど）を同じフォルダに保存することができます。これにより、モジュールに関連するCSSコードとそうでないコードを簡単に知ることができます。

モジュールが廃止されると、そのモジュールに関連付けられているすべての言語ファイルをコードベースから簡単に削除できます。モジュールを含むフォルダを削除するだけです。

明確にするために、想像したShoppingCartコンポーネントのためのこのフォルダ構造を考えてみましょう：

ShoppingCart/

- ShoppingCart.js

- ShoppingCart.css

新しいショッピングカートを作成するとします。

v2ShoppingCart/

- v2ShoppingCart.js

- v2ShoppingCart.css

同じフォルダ構成が不可能な場合

同じフォルダ内にスタイルシートとアプリケーションロジックを含めることは可能ではないか、または可能ではない場合があります。

その状況では、次の最良の選択はロジックの構造を模倣することです。例証する。コンポーネントのロジックが次のようなフォルダ構造に格納されているとします。

src/app/v2ShoppingCart/v2ShoppingCart.js

私たちはこの構造を可能な限り模倣すべきです。どんな大規模なアプリケーションでも、関連するファイルの検索が容易になります。したがって、モジュールのロジック部分のフォルダ階層を可能な限り一致させることができます：

src/app/css/v2ShoppingCart/v2ShoppingCart.css

同じ親フォルダは、ECSSを使用しているときには「ゴールド」の標準と見なされるべきですが、論理ファイルの構造を模倣すると、いくつかの利点が得られるはずです。

プロジェクト内でファイルをどのように整理するかについての具体的な考え方で、セレクタ/クラスに追加の意味と開発者の利便性を伝えることができる原則的な方法に注目しましょう。

ECSSを使用したクラスとセレクタの命名

第3章に戻って、私はCSSセレクタの名前を付けるというBEMのアプローチが私たちに与えたメリットを認識しました。ブロックに名前を付けて、そのブロックに関連する子要素を命名すると、子要素の名前空間が作成されました。

名前空間モジュールのCSSは分離の形式を作成します。他の要素との名前の衝突を防ぐことで、CSSのチャンクをある環境から別の環境（プロトタイプからプロダクションなど）に移動しやすくなります。また、あるセレクタのスタイルの変更が誤って別のセレクタに影響する可能性は非常に低くなります。

マイクロネームスペース：通常はコンテキストを指定するために使用されますが、親モジュールも示すことができます

モジュール自身の名前空間：通常、問題の要素を作成した論理ファイルの名前

名前を付けることに関しては、異なるプロジェクトでは異なることが意味をなさないでしょう。ECSSはさまざまなアプローチに喜んで適応できますが、各プロジェクトで一貫したアプローチをお勧めします。

この場合、セレクタは次のようになります。

ここでセレクタは非常にコンパクトです。セレクタをそのように記述することができれば、審美的に喜ばれます。しかし、複数の状況で暮らせるショッピングカートがあるとします。ミニカートビューとフルページビュー。その場合、コンテキストを伝えるために、マイクロ名前空間を使用することにします。例えば：

これらはどちらも真の方法ではありません。ECSSの哲学の一部は、いくつかの中核原理が不可欠であるが、異なるニーズに適応できるということである。一般的に言えば、小規模なユースケースの場合、前者の方法は問題ありません。しかし、第2のアプローチではセレクタの比較の冗長性にもかかわらず、最も復元力があり、自己文書化しています。2番目のアプローチでは、セレクタ（したがって、それが属するモジュール）と関連する要素を生成したファイルをコンテキストと認識します。

ECSS規則をWebアプリケーションおよびビジュアルモジュールに適用する方法については、第7章を参照してください。

利点を繰り返す

名前空間を持つモジュールとコンポーネントは互いに漏れないことがほぼ保証されているため、新しい設計を構築し反復することは非常に簡単です。それはこれまで考えられなかった刑罰を免れています。あなたが作成しているものの新しい部分ファイルを作成し、適切なマイクロ名前空間とモジュール名を割り当てて、あなたのスタイルを書いてください。あなたが望んでいないことに悪影響を与えないと確信しています。あなたが構築している新しいものがうまくいかない場合は、部分的なファイルを削除するだけで、他のもののスタイルを削除しないと確信しています。CSSのオーサリングとメンテナンスの信頼性 - ついに！

ソースの順序は重要ではなくなります

ルールが孤立しているので、スタイルシートのルールの順序は重要ではありません。この利点は、大規模プロジェクトで作業する場合には不可欠になります。これらのシナリオでは、部分ファイルを任意の順序でアセンブルすることが望ましい場合がよくあります。ルールが互いに分離されているので、これは簡単です。私たちの「自己検疫」ルールにより、部分的なスタイルシートのファイルグロビングが簡単になり、リスクがなくなります。いくつかの基本的なツールを使って、モジュール内のすべてのCSSパーシャルをコンパイルすることができます。

code:js

@import "**/*.css";

第9章でファイルのグロブについて詳しく説明します。

ECSS命名規則の解剖学

以下はECSSセレクターの内訳です：

.namespace-ModuleOrComponent_ChildNode-variant {}

別々のセクションを説明するために、ここでは、セレクタの解剖学的な部分が角括弧で囲まれています。

.[namespace][-ModuleOrComponent][_ChildNode][-variant]

2人以上の開発者がいると、ECSSの命名パターンに従わないコードベースへのコミットが拒否されることが推奨されます。これを容易にするために必要な工具についての情報は、第9章で説明しています。

セレクタセクションの説明

ECSSセレクタのさまざまな部分と、許可されている文字の種類に戻ってみましょう。

名前空間：これはすべてのセレクタの必須部分です。マイクロ名前空間はすべて小文字/列車の場合にする必要があります。それは、典型的には、文脈または原始論理を示す略語である。

ModuleOrComponent：上のラクダのケース/パスカルの場合です。常にハイフン文字（-）で始める必要があります。

ChildNode：これはセレクタのオプションセクションです。アッパーラクソールケース/パスカルケースで、アンダースコア（_）で始める必要があります。

バリアント：これはセレクタのさらにオプションのセクションです。小文字/電車の場合はすべて記述する必要があります。

この構文を使用すると、クラス名の各部分を別の部分から論理的に識別することができます。これらのセクションの内容と使用方法についての詳細は、次のとおりです。

名前空間

上で説明したように、HTMLクラス/ CSSセレクタの最初の部分は、マイクロ名前空間（すべて小文字/列車の場合）です。ネームスペースは、衝突を防ぎ、ルールを簡単に保守するためのソフトアイソレーションを提供するために使用されます。

モジュールまたはコンポーネント

子ノード

何かUpperCamelCaseの前にアンダースコア（_）がある場合、それはモジュールまたはコンポーネントの子ノードです。

例えば：

.sc-Item_Header {}

バリアント

何かがすべて小文字/列車ケースで、クラス名の最初の部分でない場合、それは変形フラグです。バリアントフラグは、セレクタの多くのバリアントが参照される必要がある場合に備えて予約されています。どのカテゴリ番号が割り当てられているかによって異なる背景イメージを表示する必要のあるモジュールがあるとします。このようなバリアントインジケータを使用することがあります：

.sc-Item_Header-bg1 {} /* Image for category 1 */

.sc-Item_Header-bg2 {} /* Image for category 2 */

.sc-Item_Header-bg3 {} /* Image for category 3 */

ECSSセレクタの倍増

前の例は、要素上に2つのクラスを使用するのが適切な完璧な状況を示しています。1つはデフォルトスタイルを割り当て、もう1つは仕様にバリアントを設定します。

このマークアップを考えてみましょう：

code:ecss04_01.html

<div class="sc-Item_Header sc-Item_Header-bg1">

<!-- Stuff -->

</div>

まとめ

この章では、多くの詳細について説明しました。私たちが見ていた2つの主な領域は、プロジェクトの言語ファイルをどのように整理して管理しやすくするか、ECSSでクラスとセレクタの名前を付けてDOMの要素のクラスが私たちに必要なものすべてを教える方法でしたその起源、目的および意図された文脈について知ること。また、ECSSセレクタで受け入れられている構文について詳細に検討しました。セレクタのさまざまな部分を区切るためのケーシングの違いを適用する場所と方法 これまでのところ、私たちは静的要素のみに心配してきました。次の章では、ECSSがウェブサイトやアプリケーションの変化する状態をどう扱うかを見ていきます。

-- WIP --