關於BEM的反思

反思BEM

在「學習愛BEM」中，我要代表我對BEM語法的新感覺。 我很高興地報告說，通過2年以上，我仍然對個人選擇感到滿意。

當咱們在項目中選擇代碼風格時，咱們使用BEM和ITCSS的組合。 前幾天我遇到了Spatie的指南網站。 在CSS部分，我發現了幾個讓我想到的部分。

怎麼處理孫子元素

第一個是「孫子」的概念，它不是「標準BEM」的一部分（若是有這樣的話）：

.component                      /* Component */   
.component__element             /* Child */
.component__element__element    /* Grandchild */

若是子元素在下面HTML中還有子元素怎麼辦？ 邏輯會說你會用這個孫子的方法。 個人經驗告訴我，這致使沒必要要的長類名（BEM已經有錯，而且沒有必要嘗試在CSS中反映HTML的結構。

解決這個問題花了我很長一段時間。 在CSS中反映HTML的底層結構彷佛是一個乾淨的想法。 一旦你開始應用它，雖然你會發現這致使代碼太長; 當你想改變你的HTML結構時，你須要重命名不少。

在我看來更好的是隻給你的孫子元素們一個雙重的下劃線符號加上用不一樣的名字。

若是你發現你的結構太深，你可能須要定義一個新的組件。

縮短修飾符長度

在BEM中，修飾符類用兩個鏈接符表示。 例如，咱們有一個帶有基類c-button的按鈕。 定義一個大按鈕，它是常規按鈕的變體，使用c-button--large修飾。在html中，它多是這樣的<button class="c-button c-button--large">My button text</button>

在Spatie的指南中，有一個關於修飾符的部分。 基本思想是你用「 - 」編寫修飾符，而且他們有一個責任，即他們應該只修改一件事情。

使用這種作法能夠縮短HTML，但我認爲這是有問題的。

BEM是如此強大之處在於重構。 當您重構項目時，您一般會在代碼庫的大部份內進行搜索，還有不少是跨越多文件進行搜索。

舉個例子：若是你的類命名爲c-button--large，若是你想去除它，你能夠在項目中包括javascript,html, css中搜索使用到這個字符串的地方。

使用這種方法，你能尋找到什麼？ 一個large字符串？ 這頗有可能在代碼的其餘實例中使用，例如圖像引用或不相關的javascript。

若是你寫這樣的代碼，你就是在爲本身創造了一個難以在未來重構的代碼。 固然，如今可能會更容易輸入。可是最終你會發現本身的麻煩會更大。

爲何BEM是如此的偉大？，就在於它提供了一個清晰的命名空間來講明自身的做用。不管是手動仍是編程（即經過linters）。

結論

我認爲：咱們不須要用不少沒必要要的條件來是使BEM變的更復雜，這樣會使狀況變得更糟糕

每一個人都有本身的編碼風格，這根據你的工做不一樣而變化，不少BEM / ITCSS規範沒有意義。 對於不少營銷網站來講，甚至是徹底多餘的。

我讚賞Spatie對外公開它們的內部規範。 更多的公司應該這樣作，包括咱們！

我但願這篇文章不被視爲直接批評他們的CSS指南，而是做爲對咱們所作選擇的討論的一種方式。

翻譯自Overthinking BEM

關注個人公衆號，更多優質文章定時推送