關於CSS In-In-JS和公用事業優先CSS（parwind）的想法

最近的 UI 開發任務為重新審視 CSS-in-JS 和實用優先 CSS (Tailwind) 提供了寶貴的機會。 我的日常角色很少涉及 UI 工作，因此這是一次令人耳目一新的體驗，儘管有些生疏。 我的目標是對兩種方法進行公正的比較，重點關注開發工作流程和工具。

Tailwind CSS

我們團隊選擇 Tailwind 有點自發，是出於對效率的渴望。 雖然熟悉程度各不相同，並且存在一些懷疑，但節省的時間是一個令人信服的因素。

積極方面

集成、自定義變量創建和主題開發都非常簡單。 擴展或構建新主題被證明是直觀的：

<code>@import "tailwindcss";
@theme {  
  --font-script: Comic-sans; // theme extension
  --color-*: initial;  // default overrides
  --color-white: #fff;
  ...
}</code>

包含基本樣式，即使是像默認邊距和填充刪除這樣簡單的樣式，也可以節省大量時間。 這大大簡化了工作流程。

Tailwind 的目標是提供直觀的體驗，它在很大程度上實現了這一點。 然而，有些方面感覺不太直觀。類命名約定雖然總體上很明確（例如，p 表示 padding，mb 表示 margin-bottom），但偶爾會出現不一致的情況（例如，rounded 表示 border-radius）。 這可以通過自定義主題定義來緩解：

<code>@theme { 
  --border-radius: var(--rounded);
  --border-radius-none: var(--rounded-none);
  --border-radius-full: var(--rounded-full);
  // ...etc.
  --rounded*: initial;
}</code>

總體印象

可讀性和可維護性的問題比預期的要少。 雖然語法需要一段時間的調整，並且 VS Code 的 IntelliSense 偶爾會出現滯後，但即使將多個類應用於小元素，代碼仍然易於管理且易於導航。

重要提示：避免過度依賴@apply。 這可能會導致“Tailwind-in-CSS”的不良結果。

服務器端渲染（SSR）

至關重要的是，Tailwind 在測試過程中沒有出現 SSR 問題。 它的無縫集成是一個顯著的優勢。

CSS-in-JS（情感）

2024-2025 年，CS​​S-in-JS 解決方案的受歡迎程度正在下降，這主要是由於 React 等框架中服務器組件的興起。

參見：https://www.php.cn/link/9cb4d40fce0492278209290ee3e4ae31

主要挑戰

主要問題源於對 React Context API 的依賴。 在 React 應用程序中混合服務器和客戶端組件可能會導致數據丟失並阻止重新渲染時正確的樣式更新。 這個限制是許多 CSS-in-JS 庫所固有的。

雖然存在兼容的替代方案，但根本問題仍然存在。 Joshua Comeau 的博客提供了有關此問題的精彩背景。

回顧

事後看來，轉向 CSS-in-JS 的轉變感覺沒有最初預期的那麼有利。 雖然包含的開發體驗（一個文件中的所有內容）最初很有吸引力，但隨著時間的推移，這一優勢被證明不再那麼重要。

長期考慮

CSS-in-JS 導致打字和設定開銷增加。 與Tailwind相比，感覺效率較低。 雖然條件道具傳遞提供了強大的功能和靈活性：

<code>@import "tailwindcss";
@theme {  
  --font-script: Comic-sans; // theme extension
  --color-*: initial;  // default overrides
  --color-white: #fff;
  ...
}</code>

這也會使程式碼理解和重構變得複雜。 過多的樣式覆蓋表示潛在的設計系統不一致：

<code>@theme { 
  --border-radius: var(--rounded);
  --border-radius-none: var(--rounded-none);
  --border-radius-full: var(--rounded-full);
  // ...etc.
  --rounded*: initial;
}</code>

對於新項目，我可能會避免 CSS-in-JS。

CSS 變數與主題

CSS 變數是無價的。 定義一次調色板並在組件之間重複使用它可以簡化樣式，提供與使用預定義組件變體類似的體驗。

<code>const Button = styled.button`
  background: ${props => props.variant === 'primary' ? "#ddd" : "#fff"};
`;

render(
  <div>
    <Button variant="primary">Primary</Button>
  </div>
);</code>

後處理器與設定

後處理器（例如 PostCSS）對於最佳化 CSS 至關重要。 它們具有顯著的優點：

• cssnano：刪除未使用的程式碼。
• postcss-nested：啟用類似 Sass 的巢狀 CSS。
• stylelint：提供 linting 功能。
• autoprefixer：加上供應商前綴（儘管現在不太重要）。
• postcss-import：啟用 @import 語句。

（完整清單：https://www.php.cn/link/2d280461b029134123f1f1a356e176b1）

在增加開銷的同時，後處理器還可以改善開發人員體驗和 CSS 效能。 收益往往超過初始投資。

閃電CSS

Lightning CSS（基於 Rust 的 PostCSS 替代品）提供更快的建置時間和許多相同的功能。 如果您尋求一個整合良好的解決方案，那麼值得探索。

總結

CSS 格局正在迅速發展，新的工具和方法不斷湧現。 我使用 Tailwind 和 CSS-in-JS 的經驗非常豐富，突顯了它們的優點和缺點。 RSC 對未來 CSS 工具的影響是巨大的，值得進一步考慮。

以上是關於CSS In-In-JS和公用事業優先CSS（parwind）的想法的詳細內容。更多資訊請關注PHP中文網其他相關文章！