Re從零開始的UI庫編寫生活之規範制定

FlyTeng_1874發表於2019-06-18
UI

前言

其實好久之前就想寫一些東西了，從大二開始就'入坑'了前端，這樣算來都有4年多了。話說剛入前端時，還是一個切圖仔，什麼是切圖仔呢？就是在那個前後端未分離，jquery還是1.x，php還是最受歡迎語言的時代，你只需要將設計圖還原成靜態頁面，然後在適當的位置留下替換符，就可以交給後端去處理上線釋出了，真的是相當happy，沒有這麼多花裡胡哨的東西。

當時市面上流行著不少的前端UI庫，比如最著名的bootstrap，由於當時接觸了一個有大量冗餘類名的bootstrap專案，導致一直對bootstrap有心理陰影（面對一大堆不知道什麼意思的css類簡直頭痛）。

想法 SluckyUI

編寫一個具有易記，易用，易開發等特點的高效UI庫，其中這個UI庫又細分為樣式庫和元件庫，希望這樣將樣式層解耦出來之後能在面對複雜的需求時表現得更加靈活。

這個UI庫會整合各種優秀案例，比如參考bootstrap的命名方式並進行優化，參考各種優秀的想法並加以實踐。

這個UI庫就稱為SluckyUI，引用自small-lucky，希望能讓你感到小幸運。

希望達到的程度

樣式方面盡最大可能與js解耦，能使用樣式解決的地方就不用js，讓寫樣式不再成為負擔，同時又具備一定的跨平臺性質，減輕框架切換帶來的負擔，讓開發者能專注於業務邏輯。

例如一個按鈕，直接用樣式去控制就能夠滿足絕大部分的需求，所以將常用的部分的樣式進行整合就可以了，沒必要必須寫成一個元件。

確定樣式庫規範

樣式方面將使用sass進行管理

名稱空間

名稱空間是一個樣式庫的重要根基，最出名的是BEM命名方式，但一味地使用BEM命名是難以滿足所有需求的，到最後你會發現這html裡全都是一串串難以記憶的字串，會對後續的維護構成很大的挑戰。我們的命名需要滿足易記，簡潔，易用，規範這幾點要求，我們將所用到的樣式類分為以下大概的幾個類別。

基礎樣式-能夠直觀表達所需的樣式

這型別的基礎樣式是我們平時用得最多的樣式，凡需要佈局的地方就要用到，屬性和值都非常重要，缺一不可，否則會嚴重影響可讀性，所以採用這種對屬性和值進行簡寫的命名方式。

.pt16{
    padding-top:16px;
}

.ta-c{
    text-align:center;
}

.d-f {
    display: flex;
}
...
複製程式碼

功能樣式-特殊的構造或一些hack樣式

這型別樣式的特點就是將某一種功能封裝成一個類，但這個功能用基礎樣式的方式去命名又不能直觀表達，這個時候用所對應的功能去命名就再合適不過了。

//文字超出長度後顯示省略號
.ellip {
    overflow: hidden;
    text-overflow: ellipsis;
    white-space: nowrap;
}
//出現滑動條
.limit-screen {
    max-height: 700px;
    overflow-y: scroll;
}
複製程式碼

狀態樣式-涉及到元件狀態的樣式，如表示成功，失敗，預設的狀態

狀態樣式由屬性/模組+狀態組成，我們的關注點是something & status

//普通情況
.c-success{
    color:green;
}
.c-fail{
    color:red;
}
.bg-warn{
    background-color:yellow;
}

//多狀態的情況，可參照BEM規則
.color-警示狀態-偏黑色{
    ...
}
.c-hint-b{
    color:#666;
}
.color-成功狀態-偏綠色{
    ...
}
.c-success-g{
    color:green;
}

複製程式碼

模組樣式

對於定製化程度很高的模組，則應該使用BEM命名

//如自定義的checkbox樣式模組（為了方便使用了sass編寫）
.checkbox-box-normalize {
    ...
    & .checkbox-hook {
        ...
    }
    & input {
        ...
    }
    & label {
        ...
    }
}
複製程式碼

組合樣式

以上一種或幾種樣式的組合，但這種情況比較少，比如功能樣式類.square，我們通常會有好幾個不同size的square，所以可以根據size的不同去命名這些異構的類，命名成.square36，.square72，.square96等等

確定元件庫規範

這裡只是粗略地歸納一下，詳情會在《Re從零開始的高效React+Redux專案架構》中講到。我們的UI庫暫時先僅僅關注顯示層元件。

Display component

顯示層元件，這一層的元件複用性最高，與業務的耦合程度最低。接收來自資料元件提供的資料，只關注UI與互動。

Data component

資料層元件，這一層元件與業務緊密關聯，在專案中的複用性較低，但在專案間擁有較好的複用性，例如常見的登入業務，完全可以將登入的業務邏輯封裝成一個元件供我們在不同的專案中使用。

Highorder component

高階元件，負責將資料層元件對映到顯示層元件中，起到連線作用。

結尾

在規範的思想範圍下就可以不斷地添磚加瓦了。已經整理好的元件和文件已經更新在 SluckyUI 上，可能有些地方有更好的實現方案，或者需要斧正哈哈，在接下來的時間裡會不斷地更新與維護。

以下是本系列的編寫計劃

相關文章