TailwindCSSを使うとHTMLが見づらくなる問題
ItahanaTailwindCSSが出た当初から言われている部分ですが、@applyで解決とか方法はありますが、@applyでまとめるならSassでいいじゃんと言われてしまうと思うので、現代のいっちゃんイイ方法を探りたい。
完全にコンポーネント駆動であれば、逆にデザインとコンポーネントの結合をしっかりと意識できて亜種デザインを産みづらく良いと思うのですが、そこに不満を抱くデザイナーさんもいたりするので、そういった対応に関してもTailwindCSSよりもSassの方がリーダブルに管理ができると思う。
でもTailwindCSSでCSS設計を細かく考えずに柔軟に対応できる幸せを享受したい！コンポーネント駆動でないプロジェクトでもチームに取り入れてもらいたい！
調査項目まとめ
- TailwindCSSでのHTMLが綺麗に見える方法
- @applyするならSassでいいじゃん論に新たな一石を投じる方法
- モディファイアよりも変化の大きい派生デザインが必要な場合のベターなプラクティス
サブ項目
- NextUI（v2）から探る - js密結合状態は本当にいいのか
- StoryBookをドローツールにもっと近づけて、デザイナーがノー（ロー）コードで管理できないか
- 普通のWebサイトをデザインファーストではなくコンポーネントファーストにできる方法があるか
- CSS書かなくてもイイみたいなさらに優勝できる方法とかないか
Itahanaしばらく時間をかけつつ調べながら進行します。
ItahanaNextUI のv2はTailwind Variantsという機能を持っているようです。
簡単にいうと、styledコンポーネントのバリエーション定義としてTailwindのクラスを使うってかんじですかね。
Itahanaじゃあ静的サイトでAstro使ってコンポーネントをReactで書けば良いじゃん！
というのは試してないですが、解決方法の一つになるかもしれません。
そもそもTailwindCSSを入れるか検討している時点で、既存のソースコードや制約がある場合の話ではなく、新規にサイトを作る場合の話ではあるので。
既存のソースの影響 はこのスクラップの話の範疇外だと自分にも言い聞かせておかないといけませんね。
Itahanaひとまず色々と議論・検討されている記事などを再度見て回る。
かなり同じような部分を考えてらっしゃいますね。
ただ、この時点ではコンポーネントに閉じられているならば「class属性が汚いのはメンテナンスコスト的に許容できる範囲」の解決策はなさそうで、結局世の中的にないものねだりはやめましょうということになっていそう。
著者の方も腹落ちしていない感じでしょうかね。
逆に今までのCSSってHTMLのクラス名からCSSを見にいくって大変じゃない？HTMLに何が書かれているかわかる方が実は良くない？という感じのことを書かれていると思います。
著者の方も最初は否定的だったようですが、クリティカルシンキングを経て良いと思えるようになったのだろうと想像します。
TailwindCSSと同じような思想のものがあるんですね。
ただ、そのどちらもTailwindCSSの方が良さそうと感じてしまいました。
TailwindCSSがなくなった時の〜という文脈の懸念は払拭できるかもですが、それは意味があるのか…。
有名記事や海外の記事は拾っていくとキリがないので割愛しますが、
TailwindCSSが良い悪いではなく、TailwindCSSの問題点と言われている部分を解消しつつ書き手と共有者が、”慣れ”や”我慢”以外に使いやすい方法があるならばそれを探りたい。
ItahanaTailwindCSSでのHTMLが綺麗に見える方法（を考える）
起点
HTMLのclass属性にたくさんのTailwindCSSのクラスを書いていくと、複数行になる場合もあり、HTML構造が分かりづらくなる問題があります。
エディタなどの設定である程度整えてみることはできますが、5行のHTMLがTailwindCSSを使うことで8行になってしまったり、pタグの中の文字列の倍くらい長いclass属性を見ると少し気持ちが悪い感覚になることはあると思います。
Itahana@applyは下にありますが、解決ではなく回避でしかないのと、Sassの勝利を宣言するようなものなので、それ以外で何か解決できないか探りたいと思っています。
ItahanaNextUI的な発想で、NextUIを使っていなくても変数として管理できるだろうか？
UIリストみたいなjsを用意してそこからimportしつつ、拡張できたら良さそうだけど。
Sassでいうところのextend。
しかしTailwindと自前のCSSが共存するクラスを定義する時が困るか？
それをいってしまったらNextUIもそうではあるだろうけど、Tailwindだと難しいこともあるわけで、綺麗に は短ければいいというわけではない。
ただ、自前クラスとTailwindクラス配列を混ぜつつjs変数で一発で指定できるのはそれはそれで綺麗にみえるのかもしれない。
Itahanaうーむ。
コードは汚くはないけど、メンテナブルかどうかはなんとも言えない。
Itahanaこの場合、エディタのサポート受けられない可能性が高いですね。
tailwind-variantsを使う方が賢いかも。
tailwind-variants使ってみてないから配列として取り出せるのかなどわからないので、
時間ができたら検証してみよう。
Itahana@applyするならSassでいいじゃん論に新たな一石を投じる方法（を考える）
起点
style属性は悪という考え方があり、なぜかを簡単に言うとメンテナブルではないということが挙げられます。
その他、CSSファイルに書くことによりCSSクラス名をつけることになり、管理がしやすくまた汎用化され流用ができるメリットがあります。
TailwindCSSが嫌われる主な理由がこれらのアンチであることだと思います。
TailwindCSS側としてのこの部分の回避方法に@applyすればいいというものがありますが、
じゃあSassでいいじゃんとなると思います。
Itahana上にリンクした記事にあるように、mixinなどSassに親和性のある状態なら良いなと思うのですが、それならばOpenPropsを選択した方が悩みもなく良いのではないかと思うんですよね。
ちなみにOpenPropsもPostCSSベースなので、npmでSCSSに取り込めるライブラリが公開されているのでそれらを入れる必要がありそうです。
Itahanaこれに関しては、Tailwind使っても綺麗ならそれでいいし、汚いのが許容できないならTailwind使うなの二択しかないのかも？
https://zenn.dev/link/comments/21fd1396d6b281
ここで書いたことが解決策になるかもですが、それ以外となるともう別の何かになってしまう気がするので、一旦ここはこれ以上広げない方向にしておきます。
Itahanaモディファイアよりも変化の大きい派生デザインが必要な場合のベターなプラクティス（を考える）
起点
色やサイズじゃなく、構造や組み合わせを変えたい複数のコンポーネントを含んだコンポーネントのような状態。
”Cardコンポーネントを横型にしたい” などの要件によって
Card.tsxと同じようなCardHorizon.tsxを作ってしまうことや
Card.tsx内にPropsでレイアウト情報を渡して、ちょっと無理やりな感じにレイアウトを変化させるなど。
デザイン都合によるソースコード上の仕様をなるべく減らすことができないか。
Itahana議題項目にないことを書きますが、
最近SCSSってもうオワコン化してきてないか？と思うことがある。
CSSカスタムプロパティを使っているとSCSSで使えないから結局SCSSで変数を管理しておかなきゃいけなくてJS側との疎通が悪くてめんどくさいってことが多い。
元々JS in CSS否定派というかStyledコンポーネントが好きではなかったんですが、それはSCSSに支配されていたからではないかという気がしている。
Itahanaしばらく放置してましたが、社内でも色々と聞いてみたけど、本件の考えを持つことが異端のようにも感じてきたので、郷に入れば郷に従えの精神でいいか。という気持ちも出てきた。