Sass selectors(選擇器)－該不該使用巢狀架構？
筆者最近在網路上發現了一個有趣的議題，文中討論著在撰寫Sass selectors(選擇器)時，到底該不該使用巢狀架構呢？由於講到了Sass就一定會想到它特色之一：巢狀結構(Nested Structure)，甚至可以說是Sass本身的精髓啊！所以在這裡將文中的討論提出來讓大家一起分析與思考。
首先我們將兩者的差異區別為：
寫法A
.btn { ... }
.btn_astralweb { ... }
寫法B
.btn {
&_astralweb {
...
}
}
寫法A：非巢狀
.btn { ... }
.btn_astralweb { ... }
基本上，這就是最原始的CSS寫法，所以我們直接來看此方法的優缺點吧。
優點
易搜尋：此方法最大的優點為，能夠於資料庫中輕易且快速地搜尋到此對象。當你想要的編輯對象為class=“.btn_astralweb”時，你可以直接搜尋關鍵字btn_astralweb並直接找到此對象於資料庫中對應的位置。
清晰易讀：寫法A的支持者們指出：此方法相較於巢狀式來得清晰易讀。尤其是在內容較多需要使用滑動來確認前後文時，能一眼看出此對象對應為何。
不依賴於Sass：此方法即原始的CSS處理方式，不需要依賴Sass的編譯器，且部分的支持者不太喜歡額外使用編譯器的方法。
保持平順：使用Sass時我們會很容易地寫出大量的巢狀架構，有時會過度使用使得整體相較於複雜，但使用此方法的話就能讓每個項目與項目間都看起來相對平順。(但在特殊場合時仍然保留巢狀如：加入hover/focus時，鑑別父元素與響應式時。)
缺點
不符合DRY(Don’t Repeat Yourself 簡單不重複)：在CSS的撰寫中從Sass出現後很多人開始在提倡兩個觀念，一個為DRY，另一個為KISS(Keep It Simple and Stupid 保持簡單化)，此方法最大的缺點即為此。這意味者你將要大量重複地使用你的Class Name或ID，當有多少個子項目或是需要更動時，也增加了出錯的風險：當要更改原項目名稱時。
較為冗長：相較於Sass的巢狀式結構，此方法於架構上相對的不簡潔。即使用者必須使用更多的字元來指到對應目標。
寫法B：巢狀架構
.btn {
&_astralweb {
...
}
}
此方法使用了Sass中Parent selector(父選擇器/父項目)的優點，使用&符號來作為Parent selector的前置符號。
優點
符合DRY：此方法最大的優點即為此，使用者將不需要大量且重複地使用對象名稱，可以在一處中定義其他的元件，所有的變更將自動套用於子項目上，充分地活用Sass整潔架構與其強大的優點。
簡潔：與上述的DRY相關，使用者不需要重複地寫出前置項目，我們可以只關注在如&_astralweb的部分，節省所需要使用的字元與大幅提升開發者的速度。
缺點
搜尋問題：如同在上述寫法A所提到的優點，巢狀架構可能無法直接的靠者目標對象的Class Name與ID快速地找到其所在，雖然此方法的支持者們提出能夠使用Source maps的方式，來解決這個問題，但仍有不少的人提出在較為複雜(下說明)的情況下仍然不容易搜尋到。
遺失前後文：由於使用巢狀架構我們在最後可能會看到以下的情形：
…
&_astralweb {
…
}
&_block {
…
}
...
當內容較多時由於缺少前後文，在第一時間可能無法理解這段是指什麼。什麼東西的_block?
多重巢狀：為了要使用偽元素或者響應式，我們可能至少會使用到三層的巢狀架構。這並不代表著是一件壞事，只是這很容易是巢狀架構氾濫(複雜化)的開始。
總結
不論是哪一種寫法，都確實存在著對立的優缺點，而這些優缺點都取決於開發者的習慣去選擇罷了。
其中有不少人指出他們一開始是傾向於寫法B的，畢竟Sass強大的功能(&符號、extends、mixins、include，變數等等)是何等方便，但在過度使用的情形下當一個對象涉及到了前述的所有方法時，複雜的情況就產生了，開發者將很難確切地找到所需要的位置，甚至難以對其更動。
因此，不少的人在經歷了一段時間後會選擇回頭改用寫法A，雖然較為冗長，但他們認為易讀性勝過簡潔是更為重要的。但或許是經歷的差異，筆者目前則是屬於寫法B的支持者，確實兩種方法的優缺點都有所感受；但我認為簡潔與易讀是可以並存的，妥當的使用與管理，如何避免複雜化或許才是最佳的解法。
更多電商營運與架站相關的知識，歡迎訂閱歐斯瑞電子報，以及追蹤我們的Facebook粉絲專頁！
參考資料：http://bradfrost.com/blog/post/sass-selectors-to-nest-or-not-to-nest/
我要留言