基於綜合服務平臺淺談Sass應用

1、       前言

CSS不是一種編程語言，只是單純的一行行的描述，沒有邏輯沒有變量，所以寫CSS對於習慣於運用邏輯思惟編碼的程序員來講是一件很頭疼的事。因而勤奮的程序員就開始運轉他們敏捷的大腦，爲CSS加入編程的元素，出現了一系列的CSS預處理語言，這時Sass就應運而生了。

Sass是一種基於CSS的預處理語言，在CSS的基礎上將代碼抽象和簡單化。簡單的理解，Sass分爲兩種語法，一種是SCSS，另外一種是SASS。由於新的語法SCSS和平時使用CSS的習慣基本一致，無須爲了使用SCSS而改變之前的書寫代碼習慣，使得衆多前端人員喜歡使用並廣爲傳播發揚光大（如無特別說明，本文所指的都是SCSS）。

2、       Sass的特色

Sass是基於Ruby環境的，因此真正的在項目中運用Sass，須要在電腦中構建好Sass的環境，包括安裝Ruby環境、安裝Sass、調試Sass以及編譯Sass。

僅Sass的語法外表看，和CSS能夠說是基本一致。但若想真正的運用Sass，懂得運用CSS遠遠不夠，還須要熟悉Sass的基本特徵：變量、嵌套、mixin、選擇器繼承、運算、顏色函數、命名空間、條件語句。Sass爲寫CSS提供更多的自由，像編程語言同樣，能夠給你的樣式定義變量、進行運算、構建嵌套、增長條件判斷、創建循環、賦予CSS以邏輯功能。

Sass還會提供map，這樣在谷歌瀏覽器或者火狐瀏覽器中能夠找到須要修改的SCSS文件位置，這樣也就不用擔憂引用的是CSS文件找不到相關的Sass位置的問題了。項目中不用看CSS就能夠輕鬆進行Sass的使用、修改和維護。

3、       綜合服務平臺1.0樣式

綜合服務平臺比較複雜，而且做爲一個產品，變更也是很常常的事情。像綜合服務平臺1.0那樣直接用一個個的樣式文件來講，面對着複雜多變的頁面，處理這樣那樣的樣式問題就顯得有點力不從心了。

1）加載負擔，維護不便，不利於模塊化開發

頁面中會存在多個樣式文件，增長了加載的負擔。一旦增長樣式，也是直接在樣式文件裏面追加樣式，而追加人爲了不樣式衝突可能直接用id來追加，這樣id的變動必然會引發相關樣式的變動，而若是不用id就要覈對引用的幾個樣式文件查找重複。或者說不用多個樣式文件，也是主樣式只用一個樣式文件，可是這樣的話幾個頁面都會用到的樣式部分又須要不停的複製粘貼，不管是構建樣式仍是維護樣式都很不方便，模塊化開發更是可望而不可即。

2）有規律可循的樣式不能用邏輯實現

複雜多樣的頁面結構是有規律可循的。綜合服務平臺1.0中使用樣式的時候只能把這些有規律的位置、寬度等數值一個個的算出來，想要修改也是要一個個的算出來再去修改。這對於用慣了循環、函數、變量計算的程序員來講着實是一件痛苦的事，明明能夠用循環、變量自動生成的事情卻恰恰要用計算器一個個敲。

因而咱們發現，綜合服務平臺1.0的不用預處理語言來管理樣式文件的方式不管是構建樣式仍是維護樣式都很不方便，這也激發了綜合服務平臺要用預處理語言的想法，最終在綜合服務平臺2.0中選擇了相對比較流行的Sass來管理樣式文件。

4、       Sass在綜合服務平臺2.0的應用

Sass的編程特性，能夠定義變量、能夠進行選擇器繼承、能夠計算、能夠書寫函數、能夠調用、能夠引用、能夠合併，能夠跳出循環······諸如此類，極大的減小CSS代碼的重複性與代碼的冗餘，方便維護， 可讀性更強，可維護性更強······

這些都是Sass的優點毫不僅僅是靠說出來的，在綜合服務平臺2.0中的代碼中徹底能夠體現出來。下面就挑選項目中的幾個例子來展示下它的優點：

1.   模塊化的實現

綜合服務平臺2.0經過Sass實現CSS的模塊化開發，把每一個頁面引用的CSS文件個數儘量的降到最低，經過引用和調用的結合儘量實現請求響應次數和文件大小的平衡，儘量的加快網頁的加載速度。

具體的實現方法以下： 將基礎文件分類命名，存放在不一樣的如下劃線開頭的Sass文件中，在主文件中經過@import導入須要的基礎文件，使用@extend和@include等來實現文件中所需模塊的引入，經過Sass的編譯將全部須要的樣式編譯到以主文件命名的樣式文件中。每一個基礎文件既是一個模塊也是一個模塊組，不引用不編譯，不調用不做用。

好比項目中有一個_icon.scss的基礎文件，裏面寫了不少個圖標的mixin的樣式，pageSelfInquiry.scss這個scss文件要引用的_icon.scss中的pane-btn-all這個@mixin。首先，在pageSelfInquiry.scss的頭部加上@import 」icon「；而後在對應的選擇器.pane-btn-all中寫入@include pane-btn-all引用這個icon的樣式，這樣編譯出來的pageSelfInquiry.css只會有_icon.scss中的@mixin  pane-btn-all這部分樣式，其它的樣式沒有被編譯進來。修改的時候也只是須要修改_icon.scss文件就能夠了，這樣全部引用到這個的樣式都會跟着變化，不須要一個個找着修改，大大的節省了維護的成本。

2. 變量的設置

綜合服務平臺2.0設置色調模塊運用Sass將顏色設置爲變量，並在整個項目中重複使用他們，輕鬆實現多個色調的構建，爲項目的維護和構建都節省了很多的人力和時間。用於混合器傳參，相似於函數的傳參，使混合更加的靈活，代碼更加簡潔。

在項目中，設置一個變量$themcolor做爲主題顏色，須要用到主體顏色的地方直接color: $themcolor，，改變色調時只需改變$themcolor對應的值就能夠了。

變量還能夠用於混合器的傳參，好比設置圓角大小的混合器傳參（這邊簡化代碼進行說明）。在構建mixin時給它加入參數$radius，這邊設置默認爲3px的，

@mixin border-radius（$radius:3px）{

border-radius：$radius；

}

調用這個mixin時@includeborder-radius；這樣直接生成的是3px的圓角，@includeborder-radius（5px）；這樣就生成的是5px的圓角。不須要複製粘貼，就像程序中函數的調用同樣簡單快捷。

3.16分欄佈局的實現

綜合服務平臺2.0首頁中業務系統部分的16分欄佈局是經過Sass的@for循環結合Sass的運算特性生成所須要的網格佈局。

口說無憑，代碼爲證，圖1-1是提取的項目代碼，左邊是SCSS，右邊是編譯生成的CSS文件，經過@for循環輕鬆實現16分欄佈局中各分欄寬度大小的設定，無需一個個計算，方便快捷又高效。

左邊的@for循環有點相似於程序中的forin語句，在執行這個循環的時候只須要根據算法規則寫出相應的語法，就能夠像程序中的循環同樣，完成對有規律的樣式的編譯，生成響應的CSS。這種處理方式在修改的時候也很方便，想改成12分欄的佈局的話把16改成12，60改成80便可，以此類推······

 

圖1-1

4.each循環實現圖片拼合

綜合服務平臺2.0中運用@each的list數據循環實現Sass的按鈕圖標樣式，使代碼的可讀性大大增強，與此同時，維護成本和開發成本也大大的下降。

口說無憑，代碼爲證：如圖1-2：這裏面的SCSS部分代碼在項目中是以@mixin的形式存在的，在這裏爲了方便查看給外層加上樣式名。

需求變動增長圖標時，只需替換圖片，而後在icon-data後面追加響應圖標的類名不一樣之處，圖標位置根據相應的規則進行加減，這種雖然對運算方面沒有看出有多大的便捷之處，可是對於可維護性和可讀性方面的益處倒是顯而易見的。

 

圖1-2

 

5、       注意事項

鑑於國內不少團隊花大力氣推廣Sass卻以流產了結，在此不得再也不嘮叨兩句：

1） Sass是須要學習成本的，不要讓一個對Sass不瞭解或者對項目Sass庫不瞭解的人輕易去動Sass文件尤爲是Sass庫文件，這是牽一髮而動全身的，影響的可能不止一兩個文件，也不止一兩個項目。

2） 對項目作一個合理的規劃，不要全部的sass一鍋煮。指定一個拍板規劃的人，避免團隊合做中出現文件亂套的現象。

6、       總結

Sass是一把雙刃劍，好用也很差用，Sass的諸多特色爲編寫CSS提供了不少的便利，大大的提升了開發和維護的效率，讓前端開發再也不各類複製粘貼，再也不那麼機械化，給前端開發提供了不少樂趣和靈活性，同時也爲前端開發增長了難度，對團隊的合做和管理提出了更高的要求。運用得當，事半功倍；運用不當，事倍功半，甚至功虧一簣。所以，在Sass的使用中必定要制定必定的規範和管理制度，規避Sass產生的不利因素，讓Sass更好的爲項目服務。