Must Avoid 5 Tailwind Anti-Patterns

絕對要避免的 5 項 Tailwind 反模式

#Tailwind

前言

撰寫這篇文章是因為維護的專案中有遺留一些反模式造成很多問題，這些問題其實都可以在早期被輕鬆避免，這篇文章將會介紹一些我在專案中體會到的反模式，並且提醒你千萬不要這麼做！

Tailwind 作為一款流行的工具自然也有其背後的理念，如果不了解這些理念（Utility-First、Design Token），很容易就會深陷反模式當中。

一、不善用元件架構框架

Tailwind 最適合被使用在元件架構的框架或是模板語言上，像是：React、Vue、Angular……等，雖然不使用元件來抽離管理樣式也是可行的，但你會需要依賴重複的編輯🔗，在專案規模擴大時調整樣式也會變得非常困難。請使用 Tailwind 時盡可能搭配元件框架或模板語言來抽離重複的樣式🔗。

二、濫用 `@apply`

熟悉原生 CSS 的人剛接觸 Tailwind 或多或少都會想要嘗試抽離醜陋攏長的 Class 並實踐 DRY🔗 原則，雖然雖然出發點很好，但不要因為「看起來更整潔」🔗就使用 @apply 創造新樣式。它打破了 Tailwind Utility-First 的理念導致樣式修改彈性更差、新人接手學習曲線更高、CSS 打包起來更臃腫。

@apply 是下下策，只在不使用元件、模板框架時才勉強可以考慮用來抽離一些重複的樣式。

三、濫用隨意值 (Arbitrary Values)

隨意值絕對是 Tailwind 中最受到喜愛也最容易出問題的功能，它使用起來和行內 Style 樣式一樣方便靈活，但也是因為極高的彈性會導致專案著火並迅速失控。

/* 原生 CSS */
<div style="margin-top: 200px;">
/* ... */
</div>

/* Tailwind */
<div class="mt-[200px]">
/* ... */
</div>

Tailwind 受人喜愛的原因之一就是因為它預設提供了現成的設計變數，未來就算要調整擴充或修改都非常方便，但當使用隨意值時就馬上失去了所有優勢，意味著在樣式中插入一些「寫死數值的魔法數字」導致專案難以維護。

最好分清楚獨特的數值的範圍，並且賦予一個有意義的名稱，這樣才能確保專案的可維護性，像是在 Vue 當中我可以在元件樣式中使用 CSS Variable 定義數值，並透過隨意值去使用這些變數。

<template>
  <div class="navbar mt-[--navbar-height-mobile] lg:mt-[--navbar-hegiht-desktop]">
    <!-- ... -->
  </div>
</template>
<style scoped>
.navbar {
  --navbar-height-desktop: 30px;
  --navbar-height-mobile: 60px;
}
</style>

這麼做既保留了 Tailwind 的靈活性，也有地方統一管理與標註數值的用途，可以視情況將變數定義在局部元件或模板片段當中。

四、忽略現有 Tailwind 設定

原先認為 Tailwind 只能被撰寫在元素的 class 當中，但實際上就算在客製化的 CSS 片段中也可以引用 Tailwind 的參數！可以參考 Tailwind Functions🔗，這些函式會在建構時被替換成 Tailwind 設定檔中的參數，避免使用寫死的數值。

/* theme() Example */
/* Bad */
.content-area {
  height: calc(100vh - 10px);
}

/* Good */
.content-area {
  height: calc(100vh - theme(spacing[2.5]));
}

/* screen Example */
/* Bad */
@media (min-width: 1024px) {
  /* ... */
}

/* Good */
@media screen(lg) {
  /* ... */
}

這樣的寫法在撰寫許多 Tailwind 不支援的特殊樣式或定義 CSS Variable 時會非常好用。

五、鬆散規劃與管控變數

在使用 Tailwind 時就應該同時思考如何維護管理網站的設計變數，Tailwind 提供了許多預設好用的基礎樣式，但隨著專案的擴大，你會發現自己需要定義更多的設定以滿足需求。

盡可能在設計端就定義清楚「設計當中的變數」，才能避免相同的品牌橫跨不同專案不同設計端或開發端接連爆出定義不一致的問題……近期我所在的公司也在透過導入 Figma Variable🔗來進行設計變數的統一規範。

此外區域的樣式盡量不要定義在全域的樣式中，舉例：只會出現在某些特殊頁面的設定變數，定義在全局只會白白增加專案理解負擔。

補充、使用自動化工具整理 CSS Class

就算是使用 Tailwind 一段時間其實我還是會很看不慣一堆樣式 Class 堆疊在一起，建議可以使用像是 Prettier🔗 這類自動化工具幫助你整理專案中 Tailwind Class 的順序。

你不會撰寫完一次樣式就永遠不會再改動，導入自動化工具協助整理樣式順序是 CP 值極高的投資。

總結

使用 Tailwind 之前先了解 Utility-First、Atomic CSS 的概念，善用元件或模板語言拆分重複樣式
不要留下魔法數值（缺乏解釋或命名的獨特數值）
從設計端出發並統一 Design Token

先記錄到這裡，目前觀察遇過的反模式就這幾種，包含了自身的經驗以及官方文件的建議，如果你發現專案有臭掉的跡象希望能踴躍提出來造福未來的開發者，開發的體驗需要共同維護才能保持健全，有遇到其他反模式也歡迎留言討論。

前言