從觀麥前端框架的角度看css

麥芽糖發表於2017-09-30
前端框架CSS

相容

pc web：比如 MA Station。基於chrome，可以手機訪問（需要業務做適配）。 android 上相容 微信瀏覽器 和 QQ瀏覽器，safari 支援 iOS > 8（safari 的版本隨系統版本）。比較任性。

mobile web：比如 下單系統。主要在微信瀏覽器內訪問。

safari 的相容測試可以用 mac 自帶的模擬器 simulator 來測試，非常方便。

bootstrap

基於老牌的 bootstrap，相對簡單易用。v4 現在還在 beta 中，如果正式了還是可以考慮遷移的。或者 beta 階段遷移。

less

因為 bootstrap3 是 less ，移動端基於所以也就用了 less， 實際上 sass 更強大。bootstrap4 也採用了 sass。等遷移到 bootstrap4 後我們也會採用 sass 的，就是這麼任性。

less 函式有個特性有點奇怪，我用過，不過不具備可維護性，不建議大家用。

// 正常情況

.fun1(){
    background: red;
}

.aaa{
    .fun1();
}
// 一個類名也可以當函式用，不建議用
.class1{
    background: red;
}

.aaa{
    .class1();
}

flex

web 開發都是基於 flex 的，這給我們的佈局很大的方便，非常的靈活，可以很簡單的。

上面系統的整體相容性也基本是考慮 flex 的相容上。

要特別注意的地方是 flex-shrink 即專案的縮小比例，預設為1，即如果空間不足，該專案縮小。 但是不推薦直接操作 flex-shrink，而是用 flex: none 或者 flex: auto。

移動端高清屏1px

框架用的方法是 scale(0.5) 方法。不過多介紹，(網上文章很多)[https://juejin.im/entry/584e4…

命名

沒有字首的 btn 是 bootstrap，字首 gm- 是 react-gm 庫的。 b- 是 業務內的。(連線符-)

模組內部的命名保留模組，即

// good 長是長了點，但是可維護性可讀性很強
.b-home{
    .b-home-top{
        background: red;
        .b-home-top-btn{
            background: white;
        }
    }
}
// bad 因為可能其他庫有定義了 top 這個樣式。 這樣就會有被覆蓋的可能性。
.b-home{
    .top{
        background: red;
    }
}

特殊的類名除外，比如 disabled checked error in out on off 等除外。

.b-home{
    .b-home-top{
        .disabled{
            background: gray;
        }
    }
}

less 變數命名同上，只是換成了駱駝峰，去掉了連線符

命名上有個出名的 BEM ，不瞭解，哈哈。

組合思想

目標是開發者想實現什麼樣式，通過 react-gm bootstrap 提供的類名來組合即可，這要求他們提供的類名足夠豐富。當然這個想法已經滿足了。

至於可能會出現某些場景不滿足的（肯定會有），做法是

1 是否場景不合理？也可能是故意約束，剋制，不提供此功能。
2 提出來討論，共同抽象，沉澱到 react-gm 上。
3 實在特殊的就特殊處理，直接寫在style上。

那組合思想是，其實 bootstrap 也是組合思想

<div className="gm-border gm-padding-5 gm-bg"></div>

<btn className="btn btn-primary btn-lg disabled"></div>

組合思想帶來的好處是

1 可讀性和可維護性增強，通過 className 能想象出 UI。
2 速度快，直接寫 jsx 即可。 不用來回切換 js/html css 檔案。

分離css

以前 css 是通過 webpack 打包在 js 內的，這樣帶來的壞處是

  • js 要處理這些 css，自然需要花費時間。同時還阻塞其他 js 程式碼的執行時間。
  • 按照組合思想開發，理論上 css 會很少改動，js 確實常改動。這樣 css 沒法獨立快取。
  • 如果有 dom 的話，會是先 dom 出來，之後載入 js 處理 css 部分。這時會看到頁面沒樣式，突然又有樣式的閃爍，不太好。理論上 css 最好釋放 head 提前 load。

所以就分離了唄。

降級處理

通過 autoprefixer 來做降級，比如

// 原來
display: flex;

// 處理後
display: -webkit-box;
display: -webkit-flex;
display: flex;

細心的同學可以發現，只有 -webkit-，沒有 -ms- -moz- -o-。從相容性上來考慮，只處理 -webkit- 已足夠。

css module

有短時間引入了 css module，不過現在用的很少了。 當成的目的是 css module 模組化，但是帶來了一些問題

  • css(less) 模組化後隨 js 的引入而引入，css 即非同步載入的
  • 以此同時 less 並沒有在主框架上，因此沒法使用 變數 函式 等。

於是慢慢廢棄。

隨著 react-gm 提供的類名元件完善，後面真正用到 css module 的地方少之又少。 所以後面 css module 是會被廢棄掉的。

react-gm.min.css

以前 react-gm 是提供 dist 檔案的，即 js 和 css。這樣在開發 Station 系統的時候沒有問題。

但是 MA 要求換種顏色主題，那麼就需要和 bootstrap 一樣，提供一個 theme.css 的檔案。 要抽出這 part 需要進行改造，工作量是挺大的。

後來 react-gm 廢棄了 dist 形式，直接引入 src 的 index.js 和 index.less 檔案。

庫的 css 怎麼引進來

基於上點

// ma index.js
import `react-gm`;
import `./index.less`

// ma index.less 覆蓋主題色變數即完成換主題
@brand-primary: #2c9feb;

// react-gm index.js
import `./index.less`

// react-gm index.less
@import "less/bootstrap.less";

浮層管理

這個話題也可以說 浮層的管理。開發者越少關心 z-index 越好，元件提供了封裝。 當然就需要框架考慮的東西更多了。

層級大致是

  • 正常的文件流 1
  • modal 1000
  • tip 9999

另外 modal 衍生出來的 Dialog 形態即對話方塊，要求只有一個。不能出現彈窗中有彈窗。 技術上可以做到彈窗有彈窗，但剋制，不提供相應的能力。

position fixed

移動端是禁用 position:fixed 的，不過多介紹 http://efe.baidu.com/blog/mob…

vm vh rem px

我個人是比較傾向於用 px 的。因為很簡單，切和 pc web 的開發習慣一致，也是大家開發網頁的預設單位。無須什麼轉換成本，上手就來。

當然如果是設計驅動的公司，要求高保真還原設計稿，就不太一樣了，會考慮用 rem 方案。 基於相容性考慮，我們可以直接用 vm vh。http://www.w3cplus.com/css/vw…

btw，個人還覺得 rem 在執行上很麻煩，也有對 rem 不了不深的原因。

毛玻璃

場景是對話方塊彈起來的時候背景出現毛玻璃效果。

這裡的關鍵是 背景的 dom 和 對話方塊 不能是 包含關係，然後對背景 dom 做 filter:blue(2px)。 只要管理好 對話方塊的 dom 即可。

另外關鍵是，背景 dom 什麼時機設定 filter，什麼時候取消 filter。 於是引入了事件。 對話方塊 彈起 關閉都發出事件通知到 背景 dom 即可。

框架層架構

框架層採用了 flex 佈局，給了指定區域做業務，業務只需也只能關心該區域，不能干擾其他區域，如需，需要討論商量好。

業務區域做內滾動，這 part 其實不太好，後面想重構掉。 不好的地方有，1 滾動只要指定 dom 非 document.body。 2 跟隨 dom 的彈窗不好做，需要計算位置。

css3

由於瀏覽器的環境很良好，所以可以嘗試很多 css3 的特性，也不一定是 css3，大致意思是可以用上很多高階的功能。 比如 calc、filter 等。

圖示

堅決不採用 img 來做圖示。 採用 iconfont ，我們的字型託管在 iconfont.cn 平臺。 iconfont 只能做單色，多色等不復雜的圖片。如果滿足不了則考慮 css3 或者 svg 方向。

相關文章