CSS-in-JSおよびユーティリティファーストCSS（Tailwind）に関する考え-jsチュートリアル-php.cn

CSS-in-JSおよびユーティリティファーストCSS（Tailwind）に関する考え

Linda Hamilton

リリース： 2025-01-26 08:33:09

オリジナル

501 人が閲覧しました

Thoughts on CSS-in-JS and Utility-First CSS (Tailwind)

仕事での最近の 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、マージンボトムの場合は mb)、場合によっては不一致が発生します (例: 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 に過度に依存しないでください。これにより、「CSS の追い風」という望ましくない結果が生じる可能性があります。

サーバーサイドレンダリング (SSR)

重要なのは、Tailwind ではテスト中に SSR の問題が発生しませんでした。シームレスな統合は大きな利点でした。

JS 内の CSS (感情)

2024 年から 2025 年にかけて、CSS-in-JS ソリューションの人気は低下します。これは主に React などのフレームワークでのサーバーコンポーネントの台頭が原因です。

参照: https://www.php.cn/link/9cb4d40fce0492278209290ee3e4ae31

主要な課題

大きな問題は、React の Context API への依存に起因しています。 React アプリケーションでサーバーコンポーネントとクライアントコンポーネントを混在させると、データ損失が発生し、再レンダリング時に正しいスタイルが更新されなくなる可能性があります。この制限は、多くの CSS-in-JS ライブラリに固有のものです。

互換性のある代替手段は存在しますが、根本的な問題は依然として残っています。 Joshua Comeau のブログは、この問題に関する優れたコンテキストを提供します。

回顧

今にして思えば、CSS-in-JS への移行は当初予想していたほど有益ではないと感じました。含まれた開発エクスペリエンス (すべてが 1 つのファイル内にある) は最初は魅力的でしたが、時間が経つにつれて、この利点は重要ではなくなることがわかりました。

長期的な考慮事項

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>

ログイン後にコピー