00:47
10月2日、日曜日ですね。 時刻は昨日もありました。
えー、今日もののそぎ研究活。 今日はイベントが盛りだくさんですね。
はい、おはようございます。 耳のkeethこと桑原です。
では、朝活を始めていきたいと思います。
はい、えーと、昨日がなんだっけ、ポストデブの、ポストデブが正式には、のイベントがありましたね。
ニジボックスさんとCQ協会が連携していたイベントですね。
さまざまな著名な方々が登壇されていたイベントがありまして、
確かYouTubeでライブ配信やってたんですけど、
僕は結局いろいろあって見れなかったんですけど、
ちょっとアーカイブあるかなっていうのを、ご覧の確認したいと思ってるんですけど、
それとは別で、今日です。
今日、明日ですけど、日本デジタル庁が主催するイベント、デジタルの日っていうものが、
まあ、去年もやったらしいですけどね、今年もやるそうです。
今年も豪華、いろんなゲストの方々が登壇されるっぽいですけど、
あといろんな発表があるっぽいですね。
気になりますけど、日本のトップのデジタル庁がイベントをやるっていうところで、
僕もすごく気になってるんで、
今日、明日のデジタルの日っていうYouTubeライブをちょっと見ようかなと思ってます。
確か11時から開催開始ですし、
デジタルの日だけでググっていただくと、
ちゃんと公式サイトまで飛べると思いますので、
興味ある方はデジタルの日のイベントを見てみてください。
僕はかなり気になってますね。
デジタル庁の歩みっていう公式のPDFもこの朝活で読んだんですけど、
かなりこの1年間のデジタルの日の歩みを見た感じすごく良かったので、
今後どうなっていくのか、日本のITがどのように進んでいくのかなっていうのが気になっていたり、
注目をしているのを見ようと思ってます。
すみません、余談ですね。
では早速今日の朝活の本題に入っていこうと思います。
今日はタイトルにあります通り、
テイルウィンドを考えるっていうブログを読んでいこうと思ってます。
すでに皆さん読まれたかもしれないですね。
タイプスクリプトのブルーベリー本で有名なウヒョさんという方ですね。
もともとタイプスクリプトだけじゃなくて、
いろんなJavaScriptだったり、タイプスクリプトもそうですし、
あとリアクト周りの記事をたくさん書かれている方で、
すごく、しかも一個一個の技術に対する理解が深い方ですね。
03:00
この方のブログで勉強した方もかなり多いんじゃないかと思ってます。
僕もその一人でして、そのテイルウィンドを考えるというブログを
昨日ヒョさんが書かれていて、
ToDoに入れたんですけど、またToDoに入れて読まない気がしたので、
もう朝活で読んでしまおうと思ってます。
常に読んだ方は大変に申し訳ないですけど、お付き合いいただければと思います。
では早速いきたいと思います。
今日はですね、けんじさんとプテラノドさんとすらさんですね。
おはようございます。ご参加いただきありがとうございます。
今日もダラダラと読んでいこうと思ってます。
長いんで、もしかしたら教授に終わらない可能性があるんですけど、
早速いきたいと思います。
はい、いきましょう。
皆さんこんにちは。
最近とある事情で、テイルウィンドCSSに割と真剣に向き合わないといけなくなった
弊社でありますと。
テイルウィンドCSSの話題はTwitterのフロントエード界隈では
定番のトークテーマの一つです。
しかし、弊社の考えを文章にまとめたことはなかったので、
このタイプを記事にすることにしましたということです。
まず結論からですね。
弊社が一番皆さんに伝えたいことは、
テイルウィンドCSSは考えなしに採用している技術ではなく、
採用するには熟慮が必要だということだそうです。
特にフロントエードのスタートキット的なプロジェクトの中に
テイルウィンドCSSが混ざっていることはまあまあありますが、
あれは結構なオナです。
気軽に採用すべきものではありませんと。
まあまあここまで結構そうだなと思いつつも、
でもいろんなスターターキットだけのところにボイラープレートに
既に入っているというより、それだけテイルウィンドの人気とか
伸び率がやばいということですよね。
そういうことに注目になると思います。
NPMトレンズというサイトがあるじゃないですか。
NPMのモジュールのダウンロード数ランキングとか
グラフ表示してくれるサイトがあるんですけど、
それを見る限り、もうそろそろブーストストラップの
数字を上回るんじゃないかという伸び率なんですね。
ついに歴史が変わるのかというところもありますけど、
とはいえもうちょっと時間がかかりそうな感じはしますけど、
だいぶ肉薄してきたって感じがするので、
その辺、やっぱりランキングって好きな皆さん好きだと思いますので、
僕も好きなんですけど、見てみると面白いかもしれないです。
結構数字近づいてきましたね。
はい、余談でした。戻ります。
筆者の考えでは、テイルウィンドCSSの採用を考慮に
入れてよいのは次の2つの場合だそうです。
1つ目は、デザインにこだわりがなく、
最低限整っていればいい場合ということですね。
デザイナー不在のプロジェクトなど、
デザイン上の細かな要求がないが、
とりあえず整えておきたいという場合は
採用してもよいかもしれません。
いわゆるブーストストラップ的な立ち位置のものが
欲しい場合です。
まさに同じ方向性の時ですね。
2つ目です。2つ目は、逆にデザインシステムを
しっかりと整備し、それからの逸脱を防ぎたい場合ですね。
ただデザインがあるだけでなく、
フロントエンドエンジンを巻き込んだデザインシステムを
整備したいということが主要になります。
このようなユースケースでは、テイルウィンドCSSの
アプローチが適している可能性というのがあります。
この記事では、上記の結論に至るまでの
お考えの三つ字を紹介していこうと思っています。
では行きましょう。
テイルウィンドCSSとは、
まずテイルウィンドCSSがどのような技術なのか
06:00
というのをおさらいしましょう。
一言で言えばテイルウィンドCSSというのは
メタCSSフレームワーク、あるいは
CSSフレームワークジェネレーターみたいなものですね。
公式サイトでは次のようなことに書かれています。
英文ばーっと書かれているんですけど、
ウヒョさんによる訳の方を読んでいこうと思います。
テイルウィンドには、うまく作られたデフォルトの
設定が最初から付属しています。
しかしあらゆるものがカスタマイズ可能です。
カラーパレット、スペースの大きさ、
ボックスシャドウからマウスカーソルに至るまで
全てになります。
テイルウィンドConfig.jsというのを用いて
あなたのデザインシステムを組み立てましょう。
テイルウィンドはそこからあなた用にカスタマイズされた
CSSフレームワークを生み出しますと言っていますね。
その二つ目に書かれているように
テイルウィンドのコアとなる機能は
CSSフレームワークを生成することです。
そのための材料がテイルウィンドConfig.jsに書かれた
設定というわけです。
公式サイトではこのように
デザインシステムが言及されていることから
わかるようにデザインシステムを表現することが
テイルウィンドの主要なユースケースになりますよ
とおっしゃっています。
続いていきましょう。
CSSフレームワークの特徴ですね。
テイルウィンドによって生成された
CSSフレームワークの特徴というのは
いわゆるユーティリティファーストだったことですね。
今回これが意味するところは
テイルウィンドは単一の役割を持った
クラス名を大量に生成するということです。
使ったことある方はそうだよね
という感じだと思いますね。
次のコードはコードの例が
マークアップの例が書いてあるんですけど
divタグの中にpタグが入ってあって
HelloWorldという文言が入っているんですけど
そのdivタグのクラスに
いろんなクラス名が付与されています。
例えばW-96とかH-64とか
あとFlex、JustifyCenter、BGGrey50
みたいなクラスが振られています。
書いたことある方はおなじみだと思いますね。
このマークアップというのは
普通にCSSでガリガリ書くのと大体一緒ですね。
with24remとかhight16remとか
ディスプレイFlexにするとか
JustifyContentCenterにするとか
というのをリチギリに書くとCSSでこう書くと。
テイルウィンドはさっきのクラス名みたいなのを
HTMLに直接書けばいいよという感じですね。
このようにテイルウィンドを用いて
スタイリングする場合
目的の要素に対して
直接多くのクラス名を与える形というのを取ります。
多くの場合一つのクラス名が一つの宣言に対応します。
上の例では
text-xlのみ
二つの宣言を生み出しています。
宣言はCSS用語でプロパティコロン値のことですね。
この例からわかるように
これのクラスにはデザインシステムが組み込まれています。
それはW96の96が24remを指していたり
text-xlのxlというのが1.25remを指していたりするという点ですね。
デザインシステムの元となる設定を変更すれば
96やxlの意味を変えることもできますよと。
他に普通のCSSでは
AddMediaや議事クラスを使わなければ書けないようなスタイルというのも
テイルウィンドではクラス名で書くことができます。
ここは結構楽ですよね。
09:00
例えば
md://w-48とかですね。
書くと画面の幅がmd以上ならば
w48を適用するというクラス名や
ホバーコロン、text-red-500みたいなやつですね。
やるとホバージのみtext-red-500というのが適用される
みたいなクラス名を使うことができますと。
割と直接的で見た感じは分かりやすいと思いますね。
メタフレームワークとしての特徴についてちょっと語っていきましょうと。
whfont-やtext-といった類のクラス名一式というのは
テイルウィンドCSSにデフォルトで同梱されている
コアプラグインズにも由来します。
プラグインという名称から推察されるように
これらは無効化したりまた独自のプラグインを追加することで
独自のクラス名を定義したりすることも可能になります。
このようにどのプラグインを選択するかによって
テイルウィンドが生み出す具体的なクラス名は完全に制御可能です。
このようなクラス名たちを生み出すフレームワークとしての
テイルウィンドの側面に着目をすると
キーワードや数値でパラメトライズされたクラス名一式を生み出せる点や
それに加えてMDやHoverといった
プレフィックスまで自動で面倒を見てくれる点が注目にあたりします。
もっとも筆者がこれまで見てきた通り
コアプラグインズを無効化して使っているケースは
ほとんど見たことがありません。確かにそうですね。
僕も見たことあまりないですね。
設定をいじって自らのデザインシステムに合わせつつ
コアプラグインズを活用しているというケースがほとんどです。
そのためコアプラグインズによって生み出されたクラス名たちが
Tailwindの代名詞のように扱われているというのが実情と思われます。
この記事でも以降Tailwindではという場合
特記がなければコアプラグインズの使用を仮定して
お話をしていきますよということでした。
続いていきましょう。
Tailwindは何でないかというところですね。
ここまでTailwindの特徴を紹介しました。
冒頭で述べた通り、筆者の考えでは
Tailwindはあらゆる問題を解決してくれる万能のツールではありません。
そこで何がTailwindの良分であり
何がTailwindの良分ではないのかというのを分析していきます。
TailwindはCSSの代わりではないし
CSSの学習コストを減らさないというところに入ります。
まず注意したいのはTailwindはCSSの代わりではないということです。
特にTailwindを使えばCSSを覚えなくていいということはありません。
むしろ必要ですよ。
CSS分からないのにTailwindを書くことは結構ムズいと思います。
TailwindはあくまでメタCSSフレームワーク
つまりCSSをうまく書く目のツールであって
CSSを書かなくていいというようなツールではないということですね。
Tailwindのクラス名を使用する場合
そのクラス名がどのようなCSSに翻訳されるのかというのを知っている必要があります。
例えばフレックスでフレックスレイアウトに
グリッドでグリッドレイアウトにできますが
CSSにおいてフレックスレイアウトやグリッドレイアウトがどのような挙動をするのか
理解していただければこれらは使いこなせません。
同様にz-0とかz-10で
zインデックスプロパティを指定することができますが
zインデックスのまたCSSに対する十分な理解がないと
使いこなせないことで有名です。
12:02
Tailwindを使用してその理解を省略することはできませんと言っています。
はい、というわけです。
ここは本当に完全に同意でその通りだなという感じですね。
学習コストの観点では
生のCSSの知識はどうせ必要ですから
Tailwindを使用しても学習コストは全く減りません。
Tailwindのクラス名は生のCSSに比べて簡潔なので
一見すると簡単に見えますが
その簡単さは既にCSSを理解している人が享受できるものであって
まだCSSを知らない人にとっては特に恩恵はありませんよと。
はい、完全同意です。
また既にCSSを十分理解している人から見ると
Tailwindのコアプラグインズによるクラス名が短くて簡潔だからといって
特に嬉しいわけでもありません。
エディターによる入力補完などが十分発達した現在では
Tailwindを使っても使わなくてもCSSの開発効率の差は正直ありません。
むしろTailwindのクラス名を理解するための追加の学習コストが必要なので
その分だけ不利だと言っています。
プログラミングでは関数名や変数名を無理に短くすべきではないと言われていますが
それと同じくTailwindのクラス名はやや短くしすぎて
いわゆるシンプルでなくEasyなものになってしまっている印象を受けます。
ものによっては僕もそれはわかりますね。
シンプルっていうのはいろんな無駄なものとか
冗長なものを削ぎ落として結果を見出されたものがシンプルだと思うんですよね。
タイリーはちょっと単調すぎるというものだというワードですね。
バンドルサイズの方面から見ると
クラス名が短いことによるバンドルサイズ削減というのはあり得ないわけでもありません。
しかしもともとテキストは圧縮されて配信されるものであるという点も考慮すると
よほどエクストリームなサイズ削減が必要でなければ
その誤差の範囲だとしか言えないでしょう。
これもそうでしょうね。
多分ミニファイしてもあんま変わらないんじゃないかなと思ったりします。
Tailwindは命名の苦しみからあなたを解放しないというセクションにあります。
タイトルが物語っている通りですね。
Tailwindのようなutility-firstのCSSとよく対比されるのはセマンティックなクラス名です。
これは次の例のようにセマンティックな意味を持ったクラス名
見た目ではなく内容を表すクラス名を定義し
それに対してスタイルを定義するやり方です。
例えばuserprofileっていうdivタグがあって
その下の画像にusericonみたいなクラス名を振るってやつですね。
本当にセマンティックなクラス名だと思います。
それに対して一個一個CSSを割り振っていくような感じですね。
この例ではそのuserprofileやusericonっていうのがセマンティックなクラス名です。
Tailwindに対して筆者が見かけたことがある誤解っていうのは
Tailwindを使えばいちいち命名を考えなくてもよいっていうことです。
つまりTailwindのクラス名を使えば
このマークアップは次のようになり
userprofileやusericonという名前が消えますねと。
さっきのuserprofileやusericonっていうクラス名に
いろいろCSSの設定がしてあるんですけど
それを単純にTailwindのutilityクラスをバンと直接書いてしまえば
そのクラス名使わなくていいよねっていう話ですね。
確かに名前は消えましたと。
15:00
一見すると命名のめんどくささが解放されたように見えますが
それは幻想です。
より実践的なシミュレーション、シチュエーションにおいては
マークアップが正しくこうなります。
リアクトで書かれてますね。
リアクトで書かれているんですけど
リアクトの中でもdivタグクラスネームなんちゃらかんちゃらって付いてあって
さらにusericonっていう下のほうですね。
別のタグのところにまたクラスネームなんちゃらって書いてます。
それらをラップしたそれぞれのuserprofileとusericonっていう
コンポーネントが作られてそれをレンダーしているという感じですね。
その話を結局元に戻ってみてみると
結局マークアップは適切にコンポーネントに分化されなければならず
コンポーネントを命名する必要からは逃れられないということですね。
ということでした。
リアクトで書くとそのコンポーネントに切り出すので
コンポーネントの名前を付ける時点で
結局命名してるんじゃんっていう話ですね。
これもおっしゃる通りですね。
それに加えてTailwindを書くっていうんだったら
クラス名があんま変わらんので
CSS書いてもいいんじゃないっていう気はしますけどね。
で続いてTailwind開発者による記事
CSS Utility Classes and Separation of Concerns
っていう記事があってもこれ引用されてますけど
この記事においても
ユーティリティファースの良いところは
責務の分離っていうのが達成できる点にあり
コンポーネントの概念は依然として必要であるとされています。
この記事では定期のようなコンポーネントよりも
複数のクラス名を合成した
新たなクラス名を定義することが推奨されていますが
Tailwindのドキュメントでは
定期のようなコンポーネントベースの方法も
UIライブラリを使用している場合に適した方法として
一応紹介されています。
さらに言えばTailwindのような
ユーティリティファースなアプローチを使わなくても
ReactなどのUIライブラリを使っている時点で
すでにクラス名の命名から我々は解放されていますと。
でコンポーネントに対するCSSを書く場合
クラス名の名前空間っていうのは
そのコンポーネントに制限されるのが一般的ですねと。
つまり他のコンポーネントとの
株類を気にする必要はありませんと。
そのためクラス名はラッパーとか
そういう適当な名前でも大きな問題には確かになりませんと。
これはプログラムで1行のコールバック関数なら
引数にXとかそういう命名をしてしまうのと同じということですね。
まあ確かに。
結局コンポーネントに分けてもその中はということですね。
要するにコンポーネントを作った時点で
命名の問題はすでにコンポーネントの方に移っており
これはTailwindとは無関係はできることだということです。
まあそれはそうですね。
ただ人間の行いとして命名を行うということには
変わりはないなというふうにも思いますけど。
本当にTailwindを使っていたとしても
コンポーネント分割というのは
しっかり行った方が良いとFischerは考えています。
1つのコンポーネントに属するマークアップの塊がでかいというのは
1つの関数がでかいのと同じ状態であり
通常それは望ましくありません。
またより植物的な問題として
マークアップというのは普通のプログラムに比べて
インデントが変動しやすい傾向にあり
スタイルが変更される際には
大体に修正されやすいため
壊滅的な…
じゃあ破壊的なか
コンフリクトが生み出しやすいです。
18:00
あらかじめコンポーネントで分割しておくで
破滅フラグというのを回避してくださいよ
ということでした。
まあまあまあすごい納得いくなという感じですね。
読んでいったら
実はもう今23分なんですね。やばい。ちょっと焦りますね。
ちょっと言っておきます。
Tailwindの恩恵だが
Tailwindに特有でないもの
というところですね。
Tailwindというのは複合的なソリューションです。
つまり1つの問題に1つの解決策を与える
ピンポイントなツールではなく
複数の問題に対する解決策がある程度の
オピニオンを持って統合した結果だという風に
おっしゃってます。そのためTailwindを
特定の側面だけを求めて採用すると
他の側面に足をつくわれるみたいな
可能性があり危険だとフィッシャーは考えています。
Tailwindというツールの全体を理解し
採用するかどうかを決定しなければなりません。
そこでTailwindの
様々な恩恵のうちそこまでTailwindに
特有ではない。これだけだとTailwindを
採用する理由としては弱いというのが
フィッシャーは考えているものを挙げますよという風に
言っています。
1つ目バンドルサイズもしくは
ポータビリティというところですね。
Tailwindの特徴として
その出力がCSSファイルであることが挙げられます。
そのCSSファイルを読み込むことで
Tailwindのクラス名がアプリケーションから
使用可能になります。この
方式の主な利点というのは
JavaScript側、UIライブラリー側と
素結合なところですと。
JavaScript側から依存するのは
クラス名だけでありUIフレームワークの
取り替えなどが容易になります。ところで
Tailwindは膨大な数のクラス名を
用意するので、それらの定義を含む
CSSファイルもまた非常に大きくなって
しまうのではないかという懸念がありますね。
それもそうですね。その対処として
Tailwindはバンドルサイズ最適化の機能と
備えています。プロダクション向けの
最適化をすることで
CSSファイルから実際には使われないクラス名の
定義が消されます。この機構の
強力な点はクラス名をいろいろな場所で
何回も使ったとしてもそのクラスの定義は
1つしか存在しないということですね。
ある程度の
規模のプロジェクトだと
最終のディスプレイフレックスの数を
数えると何百何千とあっても
不思議ではありません。
Tailwindの場合、実際に何百何千と繰り返されるのは
フレックスというクラス名であり
ディスプレイフレックスという定義は1箇所しかありません。
ああまあそうですね。言われてみればそうです。
さらに使っていないCSSを消し忘れて
バンドルサイズが増えてしまう
ということは原理的に発生しません。
ほう。最適化時にクラスが
消されなかったということは
マークアップの中でそのクラスの使用が
実際に検出されたということだからです。
検出は文字列検出検出検出検出検出検出検出検出検出検出検出検出検出検出検出検出検出検出検出検出検出検出検出検出検出検出検出検出検出検出検出検出検出検出検出検出検出検出検出検出検出検出検出検出検出検出検出検出検出検出検出検出検出検出検出検出検出検出検出検出検出検出検出検出検出検出検出検出検出検出検出
席も簡単にしてくれるので結構評価してますよと
これに対して注意書きがありますが
注意書きはただしこの方向性が唯一のアンサーであるとは思っていません
短期的にはモジュールバンドラーがすでにCSSはうまく扱ってくれているし
21:02
中長期的にはCSSもESモジュールズのセマンティックスの上に乗せられている
乗せられる流れが見えているからだよというふうに仰ってます
あーねーなるほどですね
まあ確かにそれはあるかも
という意味でこれが一つの回ではあるけど
絶対唯一回ではないよと同じですね
ただしこれはあくまでもテイルウィンドにおいてバンドルサイズが無駄に肥大化することはないということです
テイルウィンド以外のソリューションと比べたときにバンドルサイズでどれぐらい有利なのかはやや疑問があります
なぜならCSSのファイルサイズっていうのが削減された分のサイズっていうのは
マークアップ側でクラス名を列挙するところに転換されているはずだからですと
で生のCSSよりもクラス名の方が短いですが
前述の通り文字列圧縮をすれば差は小さくなりますと
ここでバニラエクストラクトとの比較をしていますね
はぁバニラエクストラクトすいません僕全然触ってないんですよね
触らなきゃと思いながら触ってないツールの一つでバニラエクストラクトというのがあります
この領域においてはバニラエクストラクトという競合を得ることは指摘性に値します
書き味は次のような感じです公式サイトからいいよというところで
ざっと書いてあるんですけど
いわゆるスタイルドコンポーネントの書き方に近いですね
バニラエクストラクトスラッシュCSSっていうのをインポートしておいて
スタイルっていう変数名で受け取っておくと
でエクスポートコンストのクラスネームイコールスタイルってさっき読み込んだ関数の中に
オブジェクトでCSSの設定を書くみたいな書き方ですね
思いっきりスタイルドコンポーネントっぽい感じの書き方です
バニラエクストラクトっていうのはインラインスタイルを採用している
いわゆるクラス名を変えさずに要素に対するスタイルを直接記述できるっていう点と
アウトプットがCSSファイルであるっていう点がテイルウィンドと共通しています
あ、そうなんや
こいつビルドするとCSSファイルが吐き出されるんですね
一方でユーティリティファーストクラスを使わずに
オブジェクトの形でスタイルを記述する点がテイルウィンドと異なっています
CSSの構文でなくタイプスクリプトとして書く点が少しエグゾチックですが
なるほど
よく見るとCSSのプロパティ名や値を直接使用することができており
独自のクラス名という中間層がカットされています
うん
それは確かにやっぱりいいですよね
まあそういう意味でいくとバニルエクストラクトの方が
今我々が求めているものな感じもしなくはないですけど
ポータビリティー
すなわちアウトプットがCSSファイルであるということを重要視する場合
テイルウィンドからバニルエクストラクトで選択するのが良いでしょうと
その代わりCSSで吐き出すので
CSSのバンドルのサイズとか時間が増えるよっていうのは確かにある気がしますけどね
はい、でテイルウィンドとバニルエクストラクトを選択する基準となるのは
独自のクラス名という中間層が欲しいかどうかだよってお話につきますと
そしてこの中間層の意義はフレームワークにデザインシステムが含められる点ですよねって言ってます
はい、つまりスタイルをデザインシステムで縛りたい場合はテイルウィンドを使うべきであり
生のCSSを制限なく使用したい場合はバニルエクストラクトを使うべきですと
はい、言ってますね
24:00
で、続いてインラインスタイルの話になりますね
はい、多分インラインスタイルのところでちょっと今日のサカツは終わってしまう可能性が多いにありますね
はい、今スクロールバー見てるんですけどもうちょっと続くので
はい、まあじゃあここまで読んでいきましょう
続いてインラインスタイルです
この記事ですでに触れているようにテイルウィンドでは独自のクラス名を定義することなく
DIVなどの要素に直接スタイルを与えることができます
そしてこれはテイルウィンドに特有の特徴ではありません
インラインスタイルが目的なYテイルウィンドではなく
次のような協合というのを考慮に入れるべきですと
いわゆる生のスタイル属性ってやつですね
DIVにstyle="where?"って書いてしまえば別に一緒じゃんみたいな話ですね
生のスタイル属性というのはなんかバカみたいですけど
マークアップの意味としての本質はテイルウィンドと実は何も変わってないですよと
小規模なプロジェクトなど場合によっては選択肢に上がるでしょうと
はい、生のスタイル属性の欠点はバンドルサイズが肥大化しやすい点や
メディアクエリ等は使えない点ですと
この点が問題になる場合には下記の選択肢に発展します
style="components="emotionというのが選択肢に上がりますと
はい、style="components="emotionというのは
スタイルがバンドルされたリアクトコンポーネントを作れるライブラリーですと
一見するとテイルウィンドとは毛色が違いますが
CSSプロップを使うとインラインスタイルに近い書き心地となり
メディアクエリとも扱えます
これを使う場合は次のように書けますというので
DIVタグが書いてあってDIVタグのattributesにcss="objects="の書き方で
その中に文字列リテラルでcssの設定をバーッと書いていけば
別に使えますよというお話です
この系統のライブラリーはテイルウィンドとは毛色が結構異なり
バベルまたはSWCの適切な設定が必要だったり
SSRが面倒だったりするのとやや難しい点もありますが
書き心地の良いインラインスタイルが欲しいという点では選択肢に上がります
バニラエキストラクトはさっき紹介しましたが
インラインスタイルを可能にしているということで
これも一応比較対象のライブラリになりますよというところです
ではそうですねここで区切ろうと思います
ちょっとどうしようかな
やっぱり長いんだよな
残りですね残っているセクションとしては
テイルウィンドの本質と注意点というところですね
と入っていって最後まとめで終了という感じですね
追記でまたわちゃわちゃって他にもあるんですけど
はい追記からまた結構長いので
はいちょっとすいませんけどここで中途半端ですが区切らせていただいて
また明日この続き残りを読んでいこうと思います
残り読んで若干時間余ったらどうしようかな
J3インフォの更新だけざっと
ラジオ配信的に読んで終わりにしようかなと思います
明日はですねはいということで
じゃあ今日の朝活は以上にしたいと思います
やっぱテイルウィンド僕も今アウケンで1回2回書いてみたんですけど
正直言うと結構書きやすいし
やっぱ何だかんだ使い勝手いいなと思いますけど
それはでも僕らやっぱりCSSにもう慣れ親しんでるっていうのがあって
クライアントさんの方で
なんかやっぱり内製エンジニアとか作るとか育て始めた時
チームを作ろうとしてる時に
テイルウィンドっていう選択肢を一応説明はしたんですけど
やっぱりそもそもやっぱりCSSが分からないので入れたくないですね
27:00
っていう意見を言われたんですね
これ本質分かっててこの会社さんすごい
ちゃんと何生活しようとしてるんだっていうのが分かったりっていう
お話もあって面白かったですね
ただまあ知ってる人はやっぱりバークソフトは言わないですけど
ちょっと書く量が減ったりするので
まあ早くなるなっていう印象はありますね
ただクラス名で振っとけば
CSS一個書いておいて
そのクラス名をどんどん上っておけばいいっていうのがあるので
テイルウィンドの場合それを理直に一個一個書いていかなきゃいけないってなると
実はやっぱCSS普通に書いた方が早いんじゃないのっていう気もしたりはしていたりするんですね
まあ設計とかネームスペースどうするかとかそれによって対応するので
一概には言えないですけど
まあチームの方針だったり設計だったりってところに合わせて
どうにしてもいいんじゃないかなと思ったりはしました
あとはそうですねプロジェクト的にさっき
うひょさんが書かれている通り
デザインシステムでどこまで縛るかっていうところは結構議論はあとはあるので
自分たちでしっかりデザインシステムをデザインさんが起こしていて
それを再現したいんだったら
テイルウィンドじゃない方がむしろいいかもしれないですね
僕は逆にそのデザインさんが用意したそのデザインシステムを使った
そのデザインをただただ再現するだけっていうところに
テイルウィンドを導入したことがあって
しっかり縛られてる時は逆にそれはそれでいいのかなと思ったりはしましたけど
書き心地は割と僕は気に入ってたりはしますね
これ好みの問題ですけど
実際書いてみたらわかると思いますので
この辺は皆さんのどう感じかれるかというところですね
じゃあこんなところで今日の朝勝ちは終了にしたいと思います
本日の参加いただいた皆さん大変にありがとうございました
冒頭で述べました通りですけど
今日はデジタルの日っていうイベントがあるので
興味ある方は見てみてくださいってところで
明日もデジタルの日はあるので
また明日も言及するかもしれないですけどね
というところで終了したいと思います
今日土曜日日曜日ですね
また休み2日目ゆっくり有意義に休んでいただければなと思います
では終了しますお疲れ様でした
