🍃

TailwindCSSを使いたい理由

2023/05/26に公開2

はじめに

TailwindCSSはJITモードが搭載されてからずっと使っています。
私自身、Tailwindを使うことで大幅に実装効率があがっているので、私なりのTailwindを使いたい理由を書いてみたいとおもいます。

と、そのまえに、、、

TailwindCSSを使うには学習が必要です

例えばシンプルな角丸のボタンです。

<button class="rounded border border-sky-400 text-white font-bold px-2 py-1 bg-sky-300 disabled:border-gray-300 disabled:bg-gray-300 disabled:text-gray-100">ボタン</button>

これが、

<button class="○△□×○△□×○△□×○△□×○△□×○△□×○△□×○△□×○△□×○△□×○△□×○△□×○△□×○△□×○△□×○△□×○△□×○△□×○△□×○△□×○△□×○△□×○△□×○△□×○△□×○△□×○△□×○△□×○△□×○△□×○△□×○△□×○△□×○△□×○△□×○△□×○△□×○△□×">ボタン<button>

こんな風に見えてしまっているなら、もう少し使い込む必要がありそうです。

慣れている人には以下のように見えています。

<button class="角丸、水色背景、少し濃いボーダー、白の太文字、パティング:4px 8px、非活性時はグレー">ボタン</button>

慣れている人には何が変わったのか気付くことすら出来ないのではないでしょうか。

はい、日本語で書いただけです。

いかがでですか?
ごちゃごちゃしていてどんなスタイルが当たっているか分かりづらいですか?

もしこのボタンに当たっているスタイルが一目で分かり、どこをどう変えれば良いのか瞬時に分かってしまったあなたはTailwindを習得するのに十分な理由を得たのではないでしょうか。

大量のクラスに圧倒され、しんどいと感じてしまったならそれは当たり前の事です。
誰しも最初からコードがスラスラ読めたわけではありません。

私自身も最初はドキュメントとエディタを頻繁に往復していましたし、「4の割り算」にも慣れませんでしたがインテリセンスも強力なので今ではスラスラと読み書きできるようになっています。

(ちなみに実際のエディタ上では折り返し設定が反映されるので横スクロールは発生しません。)

TailwindCSSと一緒に普通のCSSも書きます

どう考えてもCSSを書いた方がよい場面は出てきます。
大事なのはTailwindを使いたいから使っているのではなく、効率が良いから使っているということです。
CSSのほうが適しているのであれば、そこはCSSを使うべきでしょう。

プラグインを書けばなんでも作れます

例えば view-transition-name のような未対応のものでも簡単に追加できます。
もちろんインテリセンスもちゃんと効きます。

// View Transition Name
matchUtilities(
  {
    "vt-name": (value) => {
      return {
        "view-transition-name": value,
        contain: "paint",
      };
    },
  },
  {
    values: {
      image: "image",
    },
  }
);
<img class="vt-name-image" {...} />
<img class="vt-name-[arbitrary]" {...} />

クラスの動的な付け替えは昔からclassnamesだった

こういうユーティリティ関数を作りましょう。
Tailwindの重複するクラスも消してくれます。

import { clsx, type ClassValue } from "clsx"
import { twMerge } from "tailwind-merge"

export function cn(...inputs: ClassValue[]) {
  return twMerge(clsx(inputs))
}

参考: https://ui.shadcn.com/docs/installation#add-a-cn-helper

ドラッグのようなピクセル単位での変更が必要な場合

style を使用しましょう。

本題

前置きが長すぎなのですが、私がTailwindCSSを使いたい理由は大きく2つです。
この2つだけで今までCSSに費やしていた時間がかなり軽減されています。

そこだけで完結している

先に述べたようにクラス属性をみればどのようなスタイルが当たっているのか一目瞭然です。
クラスの定義まで移動する必要はありません。

同様にその場で変更が可能です。
クラスの定義まで移動する必要はありません。

マークアップと同時にスタイルを当てていくのでとても効率的です。
どこにも行く必要はありません。そこで作業を終わらせればよいのです。

また、基本的に他の要素に当てたスタイルに影響されることはありません。
変えたら変えた場所だけが変わる安心感があります。

命名の苦しみ

コンポーネントへの置き換えについてはどんな手法であれ命名がなくなることはないため考えません。

ここでいう「命名の苦しみ」とは、コンポーネントのようなある意味わかりやすいものではなく、幅や位置のようなそもそも意味などないものについての話です。
似たようなものでもこれらに違いがある場合、少なからず意味を見出そうとしますが、そもそも幅や位置自体にそれ以上の意味などないのです。
そして結局ユーティリティクラスを当てるかもしれません。

いずれにしろこれらの時間からは解放されます。

まとめ

Tailwindはメリットにたどり着く前に辞めてしまう人が多い印象を受けます。
ですが人気のフレームワークであるという事実がある以上、いざ使う必要が出てきたときに困らないように目を慣らしておいて損はないと思います。

Discussion