發現和討論函數式 CSS 的優點

函數式 CSS 的概念似乎是我這輩子聽過的最瘋狂的東西了。“我怎么會用這種玩意？CSS 已經十分出色了。”我這樣跟我自己說。

如果你從來沒有聽說過，函數式 CSS (或者說原子 CSS/通用類/不可變的 CSS —— 我可以一直說下去。這里沒有一個好的名字)是一種不去在我的 CSS 中編寫龐大臃腫的組件，而去寫能被組裝到 HTML 中大型組件的小型的，單一屬性，不可變的類的概念。

你的 CSS 可能看起來像這樣：

.p1 { padding: 0.5rem; }

.flex { display: flex }

.red { color: red; }

然后在你的 HTML 中被組裝起來：

Hi, I'm a flexbox div with 1 unit of padding and red text!

簡直是瘋了，對吧？

我熱愛編寫真的靈活，強大的 CSS 類。我主張它因為“開發者開銷的降低”。我的目標曾是一個開發者可以給一個元素加一個單獨類然后它會為他們自動地做好所有事情。基本上跟函數式 CSS 完全相反。

然后我拜讀了 Adam Morse 的史詩巨作，CSS 和可擴展性。Adam 帶你經歷了一段非常豐富的旅行，所以我推薦流出 20 分鐘時間來跟隨他的思考閱讀，但如果我必須總結一下，那就是下面的這段：

在[大型]模型中，你將永遠不會停止編寫 css。重構 css 是困難而且耗費時間的。刪除不必要的 css 是困難而且耗費時間的。而且往往不止于不——這不是人們都熱衷去做的。所以發生了什么？人們開始寫越來越多的 css。

🤔

好吧，Adam。我認輸了。你是對的。開始一個新項目以及編寫所有這些美麗的架構良好的 CSS 組件很有趣，但事實在于，我不會永遠都呆在這個狀態中，并且在大型模型中，團隊將永遠不會停止編寫 CSS。

如果你曾經走進過一個真正有優秀架構的 CSS 代碼庫的話請舉起你的手。

我也沒有。

通常來說這并不是因為代碼庫開了一個壞頭。是因為作為 CSS 的作者，我們被教導為了解決問題要拋出更多代碼。

就像 Adam，我已經碰觸到了我職業生涯中的這個點：

我對于我能使用 css 做什么已經不太感興趣。我對于我能幫助團隊里的人們使用 css 來做什么更感興趣。

Basscss 和 Adam 自己的 Tachyons 是實驗的一個優秀的起點。我在嘗試過之后被說服了，而且我有機會通過使用這個編寫 CSS 的方法來為一個新的客戶項目開球。

三個月里把函數式方法應用在 CSS 架構中之后，我已經上癮了。我曾經使用老整體方法的時代，它變成了不斷地在不同文件里跳來跳去的乏味挑戰。我想我已經信服了，但是我仍然嘗試去合理化當我的函數式代碼庫增長和發展時的可擴展性問題。

我希望能收到任何關于我考慮到或是沒考慮的問題的反饋。

益處

速度

我的天啊，我能夠快速工作了。我過去常常說我不能“在代碼中設計”并且更喜歡在像 Sketch 這樣的工具中開始任何白板設計。我開玩笑說這感覺起來就像我大腦中的兩個不同方面，只是不會相互協調。

在使用函數式 CSS 的過程中我意識到是情境的切換扼殺了我的創造力。 I'd have a great design idea,我會有美妙的設計念頭，但是緊接著我不得不切換到我的 CSS 文件中然后從草稿開始構建一個組件 —— 命名，思考盒子模型的影響，DOM 結構，最佳架構實踐等等。這就像我的創造力以一百英里每小時的速度撞到墻上。

相反，我瀏覽 DOM，編寫 HTML 而且輕而易舉地快速賦予每一個元素樣式。使用 Basscss 加上一些自定義 CSS 類用于我的主題色，我可以在一個小時內構建一個經得起時間考驗的項目主頁。

僅此感覺就足夠讓我使用這種方法。這十分令人上癮，我都不知道我是否能夠回去了。 Jon Gold 是對的：

"最好的 CSS 就是盡可能少的 CSS。"

— gold (@jongold) April 22, 2016

從設計的觀點來說，函數式 CSS 把你從在設計的時候不得不作代碼抉擇中解放出來。抉擇已經做出，而你只需要簡單地混合和匹配來以你在 Sketch 中使用形狀、顏色和間距的相同方式實現你想要的樣式。

可轉移性

在這些天里我工作的大多數項目上，我們的設計和開發團隊已經選定了設計提供 HTML/CSS 原型和開發團隊把它移植到真實環境中的想法。

這些項目的效率收益是巨大的。

一個代碼原型給了我們的設計師實踐來使用戶界面更完美而不會因為不得不學習在高級 JS 框架例如 React 或者 Angular 中工作而頭疼。

我們在這個方法中發現的問題是 HTML 需求上的一點不同：類似于需求一個會包裹在一個標簽中的組件或者指令會快速破壞掉你的 CSS 級聯。

在過去，這意味著維護一個重載的應用程序特定的集合，會隨著時間的推移出現越來越多的 bug (以及壞的 CSS 會被編寫出來)。

相反，細微的調整，例如 margin，能通過在你的 HTML 一個單獨的類變化來實現。 It allows you to fix bugs without writing any additional CSS.這允許你不用編寫任何額外 CSS 來修正 bug。我甚至不能告訴你這種感覺是多么的美妙。寫更多的代碼來修正 bug 是一種錯誤地修復你的 CSS 的方法。

停止做出(毫無意義的)選擇

Basscss 提供了一套標準的間距和大小的通用工具。消除選擇實際上就是解放。通過只提供 8px, 16px, 24px 等的間距，你只要選擇大/中/小就可以跟它一起搖擺了。

我過去以為這會帶走我所有的創造力，但是它只是使我作為設計師的生活更加愉快。我能夠專注于正確的問題上。

壞處

在進入關于函數式 CSS 問題之前，我想要變得清晰 —— 這一點上，這些都是問題而不是批評。我確信那些比我聰明的多的人們已經找出了這些問題的解決方案(或者理由)。

我很想聽聽其他人是如何解決這些問題的。

失去級聯

將組裝我們樣式代碼的責任轉移到 HTML 上意味著我們失去了所有級聯的好處。當你第一次創建一個組件的時候這是絕妙的，但是為現存的系統更新樣式就會變成搜索和替代以及其他快捷鍵的一團糟。

一個更新在一個文件一些相近樣式的簡單方法是使用多個光標在 Sublime Text 和 Atom 中，選擇一個字符串然后敲擊 ?-D (在 Mac 上) 會選擇這個字符串的下一個實例。

但是這假定了你以相同的順序放置通用類來創建多個相同的“組件”，尤其是在跨越多個頁面做搜索和替代的時候。否則，沒有一個簡單的方法來跨越你的整個頁面搜索以尋找類似組件實現的位置。

這可能是我關于在大型應用中應用函數式 CSS 的唯一的最大顧慮。想像一下一個標準的“盒子”組件由 7-10 個通用類組成。如果你想要改變所有盒子的字體大小，你需要跨越你的應用來尋找所有實例而且手動地去更新他們每一個的樣式。

這給錯誤留下了很大的空間。

組件的可重用性

使用了函數式 CSS，創建“組件”就是簡單地把一堆類放在一起搗碎。重用組件要求你在不同的地方再次使用相同的類。

再次強調：給錯誤留下了很大的空間。

這里長期的解決方案可能是實現一個模式庫來編檔組件以及提供簡單的代碼片段復制和粘貼。更勝一籌的是，通過文檔，你輕易的提供了需要時的“選項”，通過描述可以混合和匹配的類的準確類型來實現組件的變化。例如，可能一個卡片可能有不同的頂部顏色，可以輕易地通過使用 bg-color 類切換。

結合之前有關失去級聯，長期可重用性和更新的能力的問題就是我在使用函數式 CSS 工作時遇到的主要挑戰。

如果你使用組件工作，一個可能的修復方法會使給每一個組件添加一個命名類。這會是描述性的因此你實際上不會應用任何 CSS 在這個類上，但是這會用于貫穿你的代碼庫來尋找一個特定組件的實例。

.box-component 類沒有賦予任何樣式，它僅僅是一個搜索關鍵字用于尋找盒子組件用到的地方。

通用類易于實現，但是應該盡早考慮其長期可用性，可重用性以及在大型團隊中更新的能力。

響應式

如果你的設計在斷點處改變了太多的話，你的類字符串將會變得十分復雜。在早期，做一些像是 class="m2 md-m0" 這樣的事情使中間斷點之下有兩個單位的 margin 和使中間斷點之上margin 為 0 是非常好的。

但是在我的測試項目里有一個情況就是在移動端上把我的導航欄改變樣式變成一個滑動菜單，然而它在桌面端是一個標準的水平列表。這很快就失去控制了：

這僅僅是開端，更多的類會在以后出現用于定義顏色。當你的設計在斷點之間有很大的變化，實現類可能是一個挑戰(而你的類的順序是另外一個問題 —— 我們之后會討論一下)。

為了解決它，我們需要在早期建立一套有關如何處理響應式的標準 —— 例如命名約定，斷點，以及標準化最小或者最大寬度。

管理狀態

我在自己身上發現的一個普遍狀況是默認情況下隱藏一個組件，然后點擊了某個地方之后把它展示出來。我可能會寫一個像這樣的龐大 CSS 類：

.nav { display: none; }

.nav.is-open { display: block; }

在這里 JavaScript 會切換 .is-open 來展示我的導航欄。相反，我的 JavaScript 現在會切換一個通用類 .block 或者類似的類：

.block 被 JavaScript 切換來展示這個元素。這樣可讀性也不太糟糕。

為了示范，這個小組件并沒有太復雜。 然而即使在這個例子中，你也必須保證 .block 覆蓋 .hide 或者將 .hide 完全刪除(記得把它切換回來)。在更復雜的組件里，位置和樣式也會發生變化，這導致有大量通過 JavaScript 來切換的東西需要記住。

這不影響大局，但在 CSS 中制定你的組件以及只要切換一個單獨的類來處理所有樣式一定要更加簡單。

標準的類順序

任何多于一個開發者的項目都不得不設置一些關于類放置順序的標準。否則你在類的列表中尋找被應用的類時會感覺十分費勁。我個人推薦 包含模式。但在源順序之上，你的團隊應該決定所有的斷點是否應該放在一起：

把斷點放在一起

或屬性本身：

把屬性放在一起

我還沒找到哪一個更好，所以我很好奇其他的團隊是如何處理的。

文檔

在我的 CSS 里，我會常常編檔奇怪的屬性和為什么我把東西放在一個特定的地方。例如：

— Marcelo Somers (@marcelosomers) June 1, 2016

我能編檔為什么一個一個不可變的類存在于我的 CSS 里，但是把為什么我給一個特定的 HTML 元素添加這個類放到我的 HTML 標記中顯得有些奇怪。

結論

總的來說，我在使用 CSS 的函數式方法時還是很開心的。這是那些一旦你看見了你就再也忘不掉的東西之一，而且每一次當我大腦的不想改變部分嘗試去寫一個龐大的 CSS 類時，我發信我自己在構架 CSS 方面變得優柔寡斷和不感興趣。

我發現我自己想要結束編寫 CSS。我想要在項目的早期寫下一些類，然后通過把他們像樂高一樣組裝起來得到想要的設計效果。在項目的晚期才不得不去做代碼抉擇總是感覺不到位 —— 就像我在浪費我的時間用于寫 CSS 而不是實際地去解決真正的可用性問題。

我希望得到采用了這個方法的你的反饋。如果你有興趣學習更多有關函數式 CSS 的東西，我強烈推薦 Adam Morse，Jon Gold，和 Brent Jackson，他們是真正在推動著函數式 CSS 前進的人。

總結

以上是生活随笔為你收集整理的html中函数的意义,理解函数式 CSS的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。