SCSSを使用したBEMのアダプティブレイアウトの構成

多くのフロントエンド開発者がCSSでBEM方法論を使用するときに遭遇する主な問題の1つは、アダプティブレイアウトを整理する方法です。 ご存じのように、ブロックと要素は互いに独立している必要があります。また、それらが配置されているコンテキスト、つまり表示されるデバイスからも独立している必要があります。 同時に、異なる画面解像度では、ブロックは実際に異なるディスプレイを持つことができます。 このようなアイデアの適応性を整理する方法について説明しますが、外部の要因や相互に関係なく、それぞれのアイデアを使用する能力を保持します。



この問題を解決する際の一般的な方法は、ブロックのコードと、それで使用される修飾子を記述することですが、特定のタイプのデバイスとその許可に対してのみ有効です。 たとえば、.productブロックとその修飾子:.product_mobile、.product_tablet、.product_desktop。 修飾子には、特定のクラスのデバイスとアクセス許可の表現の変更が含まれ、適応性を制御できるブロックに修飾子を追加します。 多くの場合、開発者はこれらのすべての状態をブロック自体に設定し、出力ですべてのデバイスの適応ブロックを受け取ることにより、このプラクティスを無視します。 モバイルデバイス(* _mobile)でタブレットのプレゼンテーション(* _tablet)を表示する必要があるか、すべてのデバイスで1ページで1種類のプレゼンテーションのみを使用し、別のページで別のプレゼンテーションを使用するまで、この戦略に問題はありません。 表現の独立性と移植性を維持しながら、このような相互作用を整理する方法について、さらに検討します。



挑戦する



カタログとメインページの2つのページがあります。

製品ブロックには、A、B、Cの3つの表現があります。

そして、3つの画面解像度:モバイル、タブレット、PC。

サイトのメインページを表示する必要があります:A-モバイルバージョン。 B-タブレット。 C-PC。

カタログページ:C-モバイル、A-タブレット、B-PC。

追加の修飾子を追加するときにブロック表現を切り替える機能を維持することも必要です。


この段階で、6つの修飾子を作成し、異なる状況で重複しないように編成する必要があることが明らかになります。 また、適応性を失わずに、ブロックのタイプを修飾子にハードセットする機能を維持する必要があります。 場合によってはコードを複製する必要があることが明らかになります(PCの場合は「C」ビュー、モバイルデバイスの場合は「C」ビュー)。 この場合の重複を避けるために、SCSSミックスインは適切であり、最終的には3(各ブロックビュー、A、B、Cに1つ)のみが必要になります。



ミックスイン組織



ミックスインを整理するには、各プレゼンテーションを独立したものとして作成する方法と、1つのメインビューを作成して展開する方法の2つを使用できます。 作業例:





簡単な例
//    1.    ,  . @mixin type1-A() { width: 100px; height: 100px; background-color: red; } @mixin type1-B() { //   width: 100px; height: 100px; background-color: blue; } //    2.    2 ,    ,      @mixin type2-A() { width: 100px; height: 100px; background-color: red; } @mixin type2-B() { // 2  background-color: blue; } //-    .      (c.  type1-b type2-b ) .t1-a { @include type1-A(); } .t1-b { @include type1-B(); } .t2-a { @include type2-A(); } .t2-b { @include type1-A(); @include type2-B(); } //      ,   2    .   . .A { @include mix(); @include mix_A(); } .B { @include mix(); @include mix_B(); }
      
      







2番目の方法の主な利点は、コードの削減と重複の回避であり、プレゼンテーションが大きく変わらない場合に適しています。 最初の方法は、大幅な重複につながりますが、すべてを転送することなく、異なるプロジェクト間で別のタイプのビューを転送できますが、コードの可読性とその作業の理解を失うことなく、ビューを非常に変更できます すべてのプロパティは同じミックスインにあります。 これらの方法はどちらも、適応型のコードを編成するのに適しています。唯一の問題は、分解と解決すべきタスクです。



ミックスインをわずかに異なる形式に書き換えます。 これにより、最終的な表現を管理しやすくなります。



ミックスイン組織コード
 //$b -  , $m -    @mixin present_type_1($b, $m:"") { #{$m}#{$b} { //   .block-name //...code... } #{$m} #{$b}__item { //  .block-name__item //...code... &_modificator_value { //  .block-name__item_modificator_value //...code... } } }
      
      







ミックスインを整理するこの方法により、ビューの管理をより理解しやすくしながら、さまざまな方法でミックスインを接続できます。 present_type_1、present_type_2、present_type_3の3つのミックスインがあるとします。それらを接続するための可能なオプションを検討してください。



ミックスイン接続
 //      .some-block,     1 @include present_type_1(".some-block"); //      .some-block   .some-block_modificated,     2 @include present_type_2(".some-block", ".some-block_modificated"); //   @include present_type_3(".some-block", ".some-block_type_3");
      
      







実際の製品タイルに近い例:





さまざまな画面解像度のミックスインの相互作用を整理します。



適応ミックスイン接続
 // 1,  ,    @media all and (min-width:901px) { @include present_type_1(".some-block"); } // 2,    @media all and (min-width:601px) and (max-width:900px) { @include present_type_2(".some-block"); } // 3,    @media all and (max-width:600px) { @include present_type_3(".some-block"); } //   -      2.      @include present_type_2(".some-block", ".some-block_force-main-present"); // ,       3,        ,   . @media all and (min-width:901px) { @include present_type_3(".some-another-block"); } @media all and (min-width:601px) and (max-width:900px) { @include present_type_2(".some-another-block"); } @media all and (max-width:600px) { @include present_type_1(".some-another-block"); } //  .     3,    ,   2,   . @include present_type_3(".some-block"); @media all and (min-width:601px) and (max-width:900px) { @include present_type_2(".some-block", ".some-block_tablet"); }
      
      







アダプティブタイル:







これは、前述の問題を解決する方法です。 ミックスインの正しい構成とそれらの接続方法により、さまざまな画面解像度とさまざまなコンテキストでブロックを柔軟に表示できます。 同時に、ミックスインはそれ自体が独立しているため、異なるプロジェクトで互いに別々に再利用できます。



記事の冒頭で説明した問題の解決策を含む完全な例:







ボーナス



BEM方法論から戻りましょう。 親のセレクターによっては、子孫を変更するほうが便利な場合があります。 たとえば、親のクラスを変更して、商品タイルのすべての商品の表示を変更します。 修飾子product_parent_vertical product_parent_horizo​​ntalの例を見てみましょう。



レイアウト
 <div class="product-layout"> <div class="product"></div> <div class="product"></div> <div class="product"></div> <div class="product"></div> <div class="product"></div> </div> <div class="product-layout product_parent_vertical"> <div class="product"></div>    </div> <div class="product-layout product_parent_horizontal"> <div class="product"></div>    </div>
      
      







この動作を整理する例を考えてみましょう。



インタラクションの実装
 @mixin vertical($b, $m:""){/*...*/} @mixin horizontal($b, $m:""){/*...*/} //    @include vertical(".product"); // ,        ,      @include vertical(".product",".product_parent_vertical "); // ,    ,      . @include horizontal(".product",".product_parent_horizontal ");
      
      







このようなアプローチは、たとえば3番目のパラメーターをmixinに追加することでこの動作をより明示的に設定しても、言及する価値はありますが、グッドプラクティスよりもむしろ弱い決定です。



ボーナスパーツコード付きのタイル:







おわりに



このミックスインの編成方法は、アダプティブレイアウトまたはモディファイヤの編成に適していますが、個々のプロジェクト間でビューを互いに独立して簡単に転送できるため、それらを組み合わせる可能性が広がります。



All Articles