【Sass】初心者なりにRailsアプリでBEM設計を考察していく

投稿日:

プログラミング初心者の勉強ブログ #106

BEMとSassでCSSコードの整理。フロントエンドコーディングのルールを学ぶ。概念だけ知っているのと実際にやってみるは会議室と現場くらい違う。素人なりに感想と迷いどころを書いていく。

 

目次

 

整ったCSSのコーディングを考える

「整ったコーディング」とは、具体的にどのような要素を含むコードを指すのか。CSSに関わらず、基本的にどのような言語であっても、

  • 再利用性
  • 変更容易性
  • 可読性
  • 明示性

上のようなキーワードが「整ったコーディング」に含まれる要素である。Sassを勉強し、今まで書いてきた自分のCSSコードをこのような要素を満たすコードに落とし込むべく修正していく。その過程で、プリプロセッサはあくまでツールであり、その骨組みを構築するにあたって、コードの統率をとるためのルールが必要であることに気づいた。自由に書き放題の無法地帯ではコードを整えることができない。現実であれば日本という国家が法律を定めているし、会社が社訓やコンプライアンスを定めている。学校は校則を定め、髪を茶色に染めたら指導を受ける。遠足においておやつは300円まである。誰が決めたかよくわからないルールを色々守りながら生きている。普通に暮らしている限りにおいて、知らず知らず沢山のルールを守っているが、逆にルールを自分で決める機会は少ないように思う。今回はそうは言ってられない。Web制作会社で既に決まったコーディングルールに従いコードを書くのとは異なる。そのような機会が一度でもあったのであれば話は違うが、僕は独学だ。幸いなことに現代は情報社会なのでパソコンをカタカタすれば簡単に情報が入るので特に問題はない。

吉本式BEM設計(BEM設計ベース)

このサイトをみたときの「これだ」感は中々のものだった。求めていた情報が、これでもかと言わんばかりに載っていた。どうしていいかよくわからなかったBEM設計の基盤の知識を得た瞬間であった。大げさに書きすぎている。

最近気づいた自分の文章の癖は、最後にそれとなく保険の入った文章を添えることだ。今回も最後に「大げさに書きすぎている。」という保険を添えている。「大げさに書きすぎている。」と最後に添えることで、自分はこの文章を客観視していますよ、支配してますよ感を匂わせることに成功している。僕の感じ方や考え方に対し、別の人に違う考え方や捉え方をされ、共感を得られなかったときのダメージを軽減するための保険だ。もしこれを誰かが読んでいて、この文章含め僕の感じ方に少しでも共感してくれる人がいたらそれは嬉しいことだ。少なくとも、僕はこの思考回路を心から肯定的に「良い」と捉えているわけであるが、側から見れば「保険とか何言ってるんだコイツ」と思われるのが関の山なのかもしれない。そしてまたこの文章の存在自体も「保険」なのである。「コイツいっつも文の最後に保険かけてるな」に対する保険文章だ。保険の入れ子構造、ネストである。プログラミング然り、世の中は壮大な入れ子構造に溢れている。話が脱線したが、いい感じにプログラミングの話に戻れたので次に進む。

(BEM設計の指針については、リンク先見ればわかると思います。そもそもBEMの知識があまりなく、ブロックとかエレメントとか言われてもよくわからない場合は、BEMによるフロントエンドの設計この記事とかで学んでいきましょう。)

 

ディレクトリ構成

ディレクトリ構成

とにかくディレクトリ構築をまず行うべきである。型が定まらないと何も見えてこない。上の画像はRailsのstylesheets下のディレクトリ構成だ。コントローラー生成時に自動で作られる各コントローラー別のscssファイルを思い切って全て削除し無視してみた。(というよりは、上のリンクのBEM設計を丸パクリしている。やってみての感想くらいに思ってほしい。)

 

例えばmixinディレクトリの中身は、

mixinディレクトリ

こんな感じである。全てパーシャルにしている。

 

メインとなるpageディレクトリ内は、

pageディレクトリ

基本的にviewファイルと同じ名前でそれぞれ対応させている。全てが全てきっかりと定めたルール通りにいかないので、適宜妥協と最善策を考えることになる。

 

BEM設計でとりあえず守るべきこと

BEMとは、誰かが「BEM」という名前で提供してくれた設計ガイドパッケージに過ぎない。「この要素はBlockにしてね」と指示してくれるわけでない。与えてくれた設計ガイドに沿って、最終的に自分で意思決定を行い要素を切り分け分類し設計していく。なので例外は多々発生する。

以下には、日本国憲法でいう第9条くらいの地名度と立ち位置のBEMのルールや、僕が意識した要素切り分けの判断基準について書いていく。初心者である僕の「個人の考察」が含まれる内容だということをあらかじめ伝えておく。基本の要素切り分けは上に書いたディレクトリ構成の通りやっている。そこらへんはリンクを参照してほしい。

 

Blockは入れ子OKだがElementは入れ子NG

BEMの設計思考で考えると、要素の大きな固まりをBlockという名前をつけて管理する。最小単位の要素についてはElementという名前で管理する。Blockを構成する内部の要素はBlockの入れ子でも良ければElementでも良い。ただし、終点はElementにする。

これを意識して取り組んだ結果、僕の場合Blockの入れ子が4層前後になることが多かった。

 

命名規約を意識する

BlockとElementのクラス名は、セパレータ「 __ 」で区切り「Block___Element」にする。基本的にマルチクラスを定義しない。Modifierでスタイルを少しだけ変更したい場合は、セパレータ「 _ 」で区切り「Element_type_active」のように命名する。

先にも書いたがBEMの命名規約を守るとクラス名が長くなる。Modifierはスタイルを少しだけ変えたいときに用いる。可読性や明示性の観点からだと思うが、正直クラス名が長いというデメリットのダメージを引きずっている。

 

Blockの入れ子のときのみマルチクラスを定義する

あるBlockのクラス名を「.block01」とし、その内部にBlockを存在させるとすると、クラス名は「.block01__block02」となる。「block01」からみたら「block02」はElementだからである。このとき、「block02」の内部にもElementを存在させたいとなると、クラス名は「.block01__block02__Element」となってしまい、クラス名がElementの入れ子を明示してしまっているのでルール違反である。この場合「.block01__block02」の要素に「.block01-block02」というクラス名を付与しマルチクラスにする。そうすることで「.block01-block02__Element」というクラス名を成立させる。

ここで更にクラス名が長くなる。1つでさえ長めのクラス名であるのに、同じ長さのクラス名がもう一つ要素につく。ここら辺の作業をしているときが一番しっくりきていない。経験が無いからこう思うだけで、実際の現場だとこういう命名規則がテキトーだと、後々ボディーブローのように効いてくるのかもしれない。

 

2つ以上のBlockで使う要素のスタイルはmixinに定義する

要素を細分化していく中で、徐々に再利用可能なレベルまで落とし込まれていく要素が現れる。ここの判断基準は明確であり、ほとんど迷わない。考えなくてもボタンとかのスタイルは直mixin行きである。この作業はコードの再利用性が高まっていることをダイレクトに感じるタイミングであり、判断基準が明確で迷わずできるので楽しい。

 

1つのmixinにつき1つのscssファイルを用意する

mixinは贅沢にファイルを使う。個室を設ける。コード内に出てきたmixinを探すにあたって確かにわかりやすいと思う。

 

BEM設計の要素切り分けで迷ったこと

Blockの切り分け基準

先にも書いた通り、僕の場合Blockの入れ子が4層前後になることが多かった。クラス名で言えば「Block-Block-Block__Block」みたいな感じだ。細かく切り分け過ぎているかもしれないが、要素を配置するためのcontainerやwrapなどの要素もこのルールを適用するとBlockに該当させざるを得ないのでこうなった。命名規約により、クラス名がやたら長くなるのが嫌だったが、とりあえず一回言われた通りやってみた。こういうものなのか少し不安になる。container系の要素は別対応のルールを設けた方がクラス名が短くなるので良い気がしたが、下手にオリジナリティを出すのが怖かった。

 

終点のElement

切り分けが無事完了すると、全ての入れ子の終点がピュアなElementになる。と言っても、最後の最後まで突き詰めて、素のpタグやspanタグ一つをElementとして定義するのは変だと感じた。なのでここで僕は勝手に「Elementでのネストを素のタグネームのときのみOK」とした。クラスを敢えてつけないことで、この要素はこちらの設計の管理下に置いていない、だからこのElementはネストしてるがこのまとまり1つでピュアなElementだ、と明示させた(つもり)。とりあえず設計の第一歩として自分でルールを定義してみたが、答えがわからないし誰も教えてくれないのでモヤモヤが残る。

そもそもpタグやaタグはそれだけで意味を持っているし、ここら辺の細かいところは本来軽く流すくらいの気持ちであるべきなのかもしれない。

 

まとめ

最初はimportとextendとincludeが紛らわしくてどれがどれだか忘れるわと思っていたSassだったが、使ってみるとすんなり頭に入ってくれた。BEMとSassでCSSを整理整頓するのは、散らかった部屋を掃除する感じに似てるので、もっと自由に家具の模様替えみたく、いろいろ自分のやりやすいように設計を検討しても良いのかもしれない。

以上ありがとうございました。

-プログラミング学習
-, , ,

Copyright© s u p ? , 2019 All Rights Reserved.