00:05
はい、10月3日、月曜日ですね。自己話題は朝9時を回りました。
かんばんは。
えー、今日からまた、10月、本格的なスタートは今日からって感じですね。
はい、おはようございます。ひめみのkeethことくわはらです。
本日も朝活を始めていきたいと思います。
はい、本日はですね、昨日の、読んでいた記事の続きですね。
フロントエンド界隈では有名な、うひょさんっていう方の、
Tailwind CSSを考えるっていうブログ記事ですね。
のタイトル記事の続きを読んでいこうと思います。
昨日で、実は半分以上ですね。4分の3ぐらいまで読んでしまったんですけど、
今日では、残り読み切って、多分若干時間余る気がするんで、
軽くJSANインフォを更新もしあれば、それをザーッと読んで終わりにしようかなと思っております。
はい、では、月曜日ですね。朝9時からちょっと眠いんですけども、早速入っていきたいと思います。
今日は、Tailwindの本質と注意点っていうところから入っていこうと思っております。
では、いきましょう。
では、Tailwindを採用する理由となる理由はどのような点でしょうか。
弊社の考えでは、それはメタフレームワークとしてのTailwindの恩恵を受けたい場合です。
つまり、デザインシステムに応じたクラス名のセットを生成してくれるフレームワークであるということ。
この点に魅力を感じるのであれば、Tailwindを採用する理由となります。
Tailwindとデザインシステム。
弊社はデザインにそこまで詳しいわけではありませんが、フロントエンドをやる以上、デザインについて考えないわけにはいきません。
もしあなたが担当プロジェクトのデザインについてまだ考えていないのであれば、Tailwindを採用するという判断は時期焦燥であると言わざるを得ません。
まあそうね。
そもそも直接スタイルを書かずにTailwindが生成したクラス名を使うということは、CSSのフルパワーを出させてもらえないということになります。
言い方を変えれば、Tailwindはスタイルに制限をかけるということです。
制限をかけるということ自体は必ずしも悪いことではありません。
我々は普段からESLintなどを用いて機器としてプログラムに制限をかけています。
おっしゃる通りですね。
デザインの場合、使える色を特定のパレットに制限するとか、長さを8ペクセルの倍数に制限するとかして統一感のないデザインが作られて、
UXの一貫性が崩れてしまうということを防ぐことができます。
ただし、デザイナーがコンポーネントをたくさん定義してくれたとか、その程度ではここで言うデザインシステムには入らないので注意してください。
デザインが付いたコンポーネントを実装するくらいなら、どんなCSSライブラリを使ってもできます。
この記事の前半で議論したように、UIフレームワークを使っている場合、コンポーネント化というのはCSSライブラリではなくUIフレームワークの両分になります。
Tailwindの恩恵を受けられるようなデザインシステムというのは、アプリケーションの隅から隅までコンポーネントの色や大きさからコンポーネント間の隙間に至るまであらゆるスタイルがルールに縛られているようなものです。
ここまで来るとデザインシステムのルールを全てコンポーネントベースで表現するのが辛くなってくるでしょう。
Tailwindが採用しているUtility Firstは隅々までデザインシステムのルールを行き渡らせるのに適しています。
03:05
制限のかけ方は、大まかに許可リスト方式と拒否リスト方式があると考えられます。
前者、許可リスト方式は、できることのセットを用意してその中でやってもらうことを指し、拒否リスト、後者はできないことを指定してはじく仕組みです。
Linter等は拒否リスト方式である一方、Tailwindは許可リストになります。
デザインシステムにおいては許可リスト方式の方が望ましいと筆者は考えています。
CSSの表現力があまりに高く拒否リスト形式で望ましくないデザインを的確にはじくのが非常に困難だからですとおっしゃっています。
Tailwind Config.jsという取りでですね、Tailwindでは利用できるクラス名はTailwind Config.jsを元に生成されます。
どのようなクラス名が利用できるかによってデザインシステムは決定づけられることを踏まえると、
実質的にデザインシステムを定義しているのはTailwind Config.jsであるということになります。
つまり、Tailwind Config.jsに変更を加えることはデザインシステムに変更を加えるのに等しい行為になります。
これが意味するのはTailwind Config.jsに気軽に変更を加えられるような運用にすべきではなく、
このような運用はTailwindを活かせないということになります。
明確な目的意識を持ってTailwindを導入したのであれば、Tailwind Config.jsに変更を加えることには術からく慎重になるべきです。
ESLintにおきかえで考えてみれば、誰でも自由に設定を変更できるというのはおかしいということがわかるはずです。
Tailwindの設定ファイルもまたそのように取り扱わなければなりません。
続いていきましょう。
任意の値を使えるアレ。
アレですね。
ここまで説明してきた通り、TailwindはCSSでできることを制限してデザインシステムを担保するためのものになります。
制限の一つが長さ等として使える値の制限になります。
例えば、デフォルトの設定では、ウィズを設定するためのクラス名はW-16, W-20といった具合であり、
W-18といった中途半端な値は存在しません。
これによって使うべきではない長さがCSSで使われるのを防いでいます。
一方で、いつぞやのバージョンアップでW-57pxのように、仮括弧公文を用いることで制限に縛られない自由な値を使える機能が追加されました。
これは確かに、ただただ設定するとか表現するという意味では大きいというか簡単になりましたし、
正直欲しかったなというのは正直思いますが、これは筆者も書かれていますけど明らかに大きな抜け穴であり、
これまで説明してきたTailwindの意義に真っ向から反しています。
筆者もこれを知ったとき、Tailwindがどのような方向性を目指しているのかよくわからなくなりました。
Tailwindをデザインシステムのために使っている限り、この機能は明らかに乱用すべきではありません。
タイプスクリプトでいうところのエニーやアズに相当するものです。
この機能はTailwindがわざわざ提供してくれた不便さを覆して、便利にスタイルを書けるようにしてくれるものですが、
06:01
だからといってTailwind以外に比べてなお便利になるわけではなく、マイナスをゼロに戻しただけです。
この機能をフル活用する場合は、もはやTailwindの特徴がクロス名が短いぐらいしかなくなってしまいます。
記事の前半で述べた通り、筆者の考えでは短いことは別に良いことではないので、この機能を使う意味がありません。
たまに使い道があるかもしれないとはいえ、リンターとかでデフォルトは禁止にしておきたい機能ですねと皆さんも注意しましょうとおっしゃっています。
Tailwindはどれぐらい効果があるのかというところですね。
前述の通り、Tailwindは制限を通じてデザインシステムの遵守を担保する効果があります。
Tailwindを使ってスタイリングすることで要素間のマージン一つに至るまでデザインシステムのルールが行き渡ります。
またフロントエンドに携わるエンジニアの間では、デザイナーが作ったデザイン幹部は1ピクセル単位で忠実に再現するためのものではないという説が人気です。
その場合にTailwindからデザイン幹部から実際の実装に起こす際にデザインの完成さが損なわれるのを避けることができます。
一方でTailwindに従っているからといって何をしてもOKというわけでもありません。
ボタンとボタンの間隔が意味もなくM-2だったりM-3だったりしたらおそらく良いデザインにはならないでしょう。
このことからデザインに関してはTailwindに任せておけば心配なしというわけではありません。
デザイナーがいるにせよいないにせよ人間の英知が依然として必要になります。
そのため弊社の考えではTailwindはデザインシステムの推進という面においてそこまで強力ではなく控えめなリンターのような印象です。
意外とストライクゾーンが狭くTailwindがしっかりはまるプロジェクトというのは実は滅多にないのではないかなというふうな気がしています。
それでもないよりはましで生産性が上がりそうとも感じています。
まあこうですね、ストライクゾーンが狭いというのは確かに今までの読んできた感じでは同意だなと思いますね。
ではまとめですね。
この記事全体を通して主張してきたようにTailwindの本質的な利点というのはメタCSSフレームワークであるという点であります。
デザインシステムに由来する制限をスタイリングにもたらすことができるという点です。
デザインシステムを強制するという観点からはTailwindの主法は筋がいいと弊社は考えています。
それ以外の点、バンドルサイズが小さいとかクラス目が短いとかは大体の手段があったりそもそも利点ではなかったりするためそちらを目的にしてTailwindを採用すべきではありません。
そうしてしまうとTailwind特有の制限であったりオーバーヘッドが煩わしく感じるでしょうと。
結論としてTailwindの採用を検討してもいいと弊社が考える場合を再掲します。
1つ目、デザインにこだわりがなく最低限整っていればいい場合。
デザイナー不在のプロジェクトなどデザイン上の細かな要求がないがとりあえず整えておきたいという場合は採用しても良いかもしれません。
ブートスラップ的な立ち位置のものが欲しい場合です。
この場合は厳密にはTailwindじゃなくてもいいし他のUAフレームワークがたくさんあるのでどれを使ってもいいんじゃないのというような気はしてますね。
ただ細かいところ、ちょっとでも外れた瞬間そのUAフレームワークっていうのは急に牙を剥いてくるのでTailwindの方が僕はいいんじゃないかなと思ったりしますね。
09:00
もう1個ですね。
2つ目は逆にデザインシステムをしっかりと整備しそれからの逸脱を防ぎたい場合ですよとおっしゃってます。
ただデザインがあるだけでなくフロントエンドエンジニアまで巻き込んでデザインシステムを整備したいということが重要です。
このようなユースケースではTailwind CSSのアプローチが適している可能性がありますよというふうにおっしゃってます。
これもずっと書いてきた、読んできたものその通りだなと思いますね。
では追記ですね。
ここからは追記です。
この記事は結構反応いただいたので確かにと思った点について追記しますと。
1つ目、命名の苦しみについてです。
特に異論が多かったのはその命名の苦しみに関する点です。
本文では次のようなコードを例示しましたが、
1要素1コンポーネントにはしないのでコンポーネントの中でクラス名を命名する手間が省けているというような反論が多くありましたと。
実際に本文で使われた記事のソースコードですね。
ユーザープロフィールっていうコンポーネントとユーザーアイコンっていうコンポーネントを使っていて、
ユーザーアイコンはユーザープロフィールコンポーネントにラップされている。
チルドレン的な存在ですね。
それぞれの中にクラスネームなんちゃらみたいなのが個要素の中で貼られているという感じですね。
つまり実際には定規のような、ではなく下記のようなコンポーネントになることが多く、
その場合ディブとイメージに対してスタイルを当てる必要があるということですと。
今のはユーザーアイコンとユーザープロフィールをガザーと別に分けて、
ユーザーアイコンに対してしかもイメージタグしか置いていないコンポーネントだったりしますけど、
実際にはそんなコンポーネントに分けずに、
普通にディブタグでイメージってガンって置くことが多くないみたいな話をされていますね。
結局その時はディブタグとイメージタグ両方にスタイルを当てる必要があるよねっていうところで、
意外とおっしゃっていたところに反論じゃないのっていうところが、
手間が省けているんじゃないのっていうところがあったりするよっていう話をされていました。
これについてはヒッシャーも同意するところで、
ヒッシャーが実際に実装するならば、
このようにディブとイメージを一つのコンポーネントにまとめると、
今回のソースコードの例みたいにコンポーネントは分けないよっていうふうにおっしゃっています。
インラインスタイルを使わなければ次のような感じになるでしょうというところで、
クラスネームのところがclasses.wrapperとかclasses.icoみたいなので、
いわゆるCSSのスタイリングのところを一つのJSのオブジェクトにガンと埋め込んでおいて、
それを適宜必要なところに置いていくみたいな感じですね。
いわゆるCSSJSまさにそれっていう感じの書き方をするというところでした。
その時はwrapperとiconsという2つのクラス名の命名をする必要が出てきますよねっていうことでした。
なので本文の構成というのは最適な説明ではありませんでしたと素直に反省しますということでした。
こうなった理由としては複数の論点を混ぜるのを避けたかったという点と、
ヒッシャーがwrapperやiconsといったクラス名を用意することを全くに感じていなかった。
これは感覚の違いですね。
wrapperやiconsという名前を考えることを省略できる程度では利点にならないと思ったという点があります。
僕もwrapperとかコンテンツとかコンテナーとか使っちゃいますけどね。
昔ながらっていうのもあるし、認識としては僕は分かりやすいなと思ったりしているので。
これについて一応注意書きがありますね。
12:00
お前じゃなくてチームの生産性のことを考えろというような意見もあるかもしれませんが、
名前はクラス名に関わらずエンジニアリングに必要なスキルなので、
この程度のスコープの話であれば、携わる人の能力を伸ばす方に導いた方が賢明だと思います。
成長とか育成的な観点でもそっちにした方がいいんじゃないのっていうのは、
これは素晴らしいご意見ですね。なるほどでした。
ポイントは本文で説明している通り、クラス名はコンポーネントの名前空間に閉じるので、
そのコンポーネント内で意味が通じれば良いということです。
そのためクラス名はユーザーラッパーやユーザーアイコンよりはラッパーやアイコンとします。
上のコンポーネントなら、ヒッシャーはラッパーやアイコンといった命名を2秒くらいで考えるので、
そこを省略できることにあまり意味を感じていません。
またコンポーネント名は後から名前を変更しやすい一方で、
クラス名は変更しにくいという意見も見られました。
クラス名がコンポーネントの名前空間に閉じていれば、名前の変更は十分に可能です。
もしコンポーネント内のクラス名を2秒で考えられないくらいコンポーネントが複雑化したら、
その時がコンポーネントの分け時だというのがヒッシャーの考えです。
わかりやすいですね。
例えばアウターラッパーとかラッパー、インナーラッパーができたみたいな笑い話も耳にしますが、
ヒッシャーも実はやったことがありますが、
そういう構成が発生するのはCSS上の都合であることが多いので、
そのレイアウトを担当するコンポーネントを分離して、
役割に応じた名前を付けた方が良いです。
フレックスコンテナーとかアイテムとかみたいですね。
とはいえ、実際に記事の反応を見てみると、
ラッパーというクラス名1つすら付けたくないという意見が結構見られました。
はあ、そうなんや。ラッパーというクラス名付けたくない人いらっしゃるんですね。
てかその人結構多いんですね。
時代の違いか、文化の違いかって感じはありますが。
そのような方にとっては、確かにクラス名がないということは利点になるかなと思います。
そのような方にとっては、
命名の苦しみからあなたを解放しないは言い過ぎでゼロにはなりませんが、
苦しみを削減できるという利点があるでしょうと。
ただし1点注意しておきたいのは、
クラス名を書かなくていいのは、
インラインスタイル全般の利点であって、
テイルウィンドに特有ではないということです。
テイルウィンドを採用する利用になるべきなのは、
デザインシステムであるという主張は変わっていません。
なお、命名に関しては記事を書いてくださった方もいます。
こちらもぜひ参照くださいというところで、
テイルウィンドの命名を先送りできる嬉しさという記事が貼られています。
これ読んでみようかな。はい。
JavaScriptがない場合について、上の話もそうですが、
UAライブラリなどを用いてコンポーネントができることが前提の議論となっています。
そうなると、ちょっとしたLPを作成する場合や、
完全なMPAですね、マルチページアプリケーションですね、
の場合など、そもそもUAライブラリを使わないケースで、
テイルウィンドの利点が出るのではないかという件もありました。
このケースはこの記事の考慮から漏れていたので、
普通にそうだと思いました。
グローバルにクラス名の管理をするのが辛いというのは歴史が証明しており、
JavaScriptを返さない方法の中ではテイルウィンドが有力な選択肢になると思います。
バニラエクストラクトともちゃんと差別化もできていますということですね。
そういう案件はかなり辛いというか、プロジェクトは辛そうなところですけど、
確かにそうだというか。
というところで、この記事は締められています。
いかがだったでしょうかね。
そのテイルウィンドについての考察。
やっぱり一本も二本踏み込むの考察だけあって、
15:02
とても共感もあるし、そうだなという感じもありますね。
僕も何案件かテイルウィンドを書いたことがあるので、
便利だなと思う反面、これはどっちかというと技術とか開発環境ではなくて、
やっぱりチームビルディングとか、
デザイナーさんとの立て分けだったり、コミュニケーションの仕方だったりとか、
そこまで含めて意思決定をするべき技術なんだなというふうに思いました。
逆に言うとそれだけ汎用性が高いというふうには証明にもなるし、
ここまでなんですかね、
本当は技術って導入するチームのことを考えてから導入するのが、
選定をするのがいいんだろうなというのを改めて考えさせられましたね。
これでもフロントエンドの話かもしれないですね。
サーバーサイドはちょっとわからないですという感じです。
では残りの時間で、J3インフォーを読もうと思ってたんですけど、
今貼られていたテイルウィンドCSSの命名を書き送りできる嬉しさというのは、
せっかくなのでこのまま読んでいこうかなと思いましたので、
いきたいと思います。
前提として、テイルウィンド好きとして
うひょさんのテイルウィンド考えるの記事を読ませていただき、
とても共感でしたよということでした。
テイルウィンドとデザインシステムというところですね。
CSSフレームワークジェネーターの視点が欠けたままテイルウィンドを語れることも多いです。
デザインシステムを作る、または将来作りやすくするためのフレームワークくらいの認識が広まってほしい。
とても良かったので、ぜひ元記事を読んでから進んでいただけるということでしたので、
今からいきたいと思います。
テイルウィンドは命名の苦しみからあなたを解放しないのか?というところです。
1点だけここについて基本同意の上で思うことがあったので、
視点を補足的にネットに残しておきたいと思います。
命名の苦しみからあなたを解放しないが、
命名の苦しみを減らすことができるとも思っています。
先送りできるからということですね。
命名を先送りにするとはどういうことでしょうか?
あるページをマークアップしていくとき、
いきなり最初の理想のコンポーネントを作ることは難しいではないだろうか?
これはもうそのままですね。
多くの場合、まずページ全体や大きめのコンポーネントにHTML、CSSを書いていき、
必要に応じてコンポーネントを分割していくことが多いのではないだろうか?
そうなんですか?
普通大きめのコンポーネントとかにHTML、CSSをガッと書いて、
必要に応じて分割していくことが多いんですか?
意外でした。
僕がよくやる環境的には、まずAtomsをガッと作って、
そこからそれをどんどん組み合わせて、組み合わせて、
コンポーネント、ページを作っていくみたいな感覚で、
一番末端のAtomsから僕らは着手することが多かったですし、
デザイナーさんがデザインシステムを作ってくれたり、
いわゆるパーツレベルのところのスタイリングとかデザインのルールみたいなのを
そこで定義してくださっているので、
そこから作っていくことが多かったので、ちょっと意外でした。
戻りましょう。
もちろん作っていった過程で、後から分化しましょうって話は別で議論出てくるんですけど、
それはその時、その時、都度チームで話せばいいと思っていたので。
例えば元記事にあるこちらのコンポーネントを例に使わせていただく。
ユーザープロフィールとユーザーアイコンというコンポーネントで、
親の方のユーザープロフィールはDivタグの中に
チルドレンがガンと置いてあるだけです。
ユーザーアイコンは単純にイメージタグがガンと置いてあるだけです。
それをユーザープロフィールのコンポーネントの中に
ユーザーアイコンのコンポーネントをガンと置いていると、
挟んであげますよってことですけど、
最初からこのように書くのではなく、
18:00
初めはこのようにコンポーネントを分割するのではないだろうかというところで、
ユーザープロフィールコンポーネントの中に
Divタグとイメージタグがあるよってそのままですね。
これをテールウィンドウを使わずに、名付けずにスタイルを書くならば
このようになるだろうというので、
単純に暮らすのがユーザープロフィールっていうところに
親の方のスタイリングをしてあって、
ユーザープロフィールのスペースを入れてイメージですね。
いわゆるネストしたところにスタイリングを書いていくと。
クラス名も別に振らずに、
単純にタグ名だけをゴンと置いちゃうみたいな感じですね。
この時点でドットユーザーアイコンみたいな風に名付けて
よかったっていう風に、
名前を先送りにしましたということであります。
テールウィンドウを使わないと先送りにできないのかっていうところですけど、
先ほどの例ではテールウィンドウを使わずとも
名前を先延ばしにできているようには見えますが、
イメージにスタイルを当てることはあるんだろうかっていうところですね。
先ほどのJSSスタイリングは説明しなかったんですけど、
単純にウィッズとハイドのピクセルを
ポンと指定しているだけだったりします。
コープトスタイルになっている小さなコンポーネントなど、
影響範囲が見渡せる状態であれば、
htmlタグにスタイルを当てるパターンは個人的にありだと思っています。
確かにですね。
本当に末端レベルであれば別にクラス名振らないで
そのままタグにスタイルを当てる方も確かにあると思いますね。
でも影響範囲を把握できない箇所に
htmlタグに直接スタイルを当てるってことはしないでしょうと。
例えばイメージが2つ使う必要があった場合に
クラスを使わずに書くことってのはあまりないよねってことでした。
書く人もいますけど、
このパターンは口実ってところですね。
何だっけ、日本語の名前忘れましたけど
右の大なりとか小なりみたいなやつを書いて
スタイルをすることが多いですねってことですね。
つまりコンポーネント分割していない状態で
クラス名を命名することになりますと。
一方、Tailwindは直接htmlにイメージタグの中で
クラス名もホゲホゲみたいなのを書いていくので
命名しなくてもスタイルを完全に当てることができると。
つまり命名することがなくなると。
今回補足した1点のポイントを整理すると
命名とコンポーネント分割のタイミングは違うという点ですよと言ってます。
そしてTailwindは分割のタイミングで
初めて命名すれば良いというのが嬉しいとこの方はおっしゃってます。
なぜ先読みできると嬉しいのかってところですけど
意見が分かれるかもですけど
私はやぐに的にコンポーネント分割は
必要になったタイミングでした方が良いと考えています。
これは僕も結構共感ありますね。
私の考える必要になったタイミングっていうのは2つありまして
1つ目はループ処理を含む2箇所以上で
同じレイアウトが必要な時に分割をしましょう。
2つ目はスタイル影響範囲が把握が難しくなって
スコープを区切りたい時っていうのが
スタイルに関するものとして主な理由ではないでしょうか
というのをおっしゃってます。
確かにそれはよくわかりますね。
嬉しいポイント1です。
構造化とレイアウトには要は集中ができると。
イメージが付くように具体例として
この部分をマークアップするとすると
全の普通にトップページのところに
カテゴリー分けがあって
そこに記事のリンクがばーっと貼ってあるじゃないですか。
その画像がそのまま貼られてますと。
私ならば最初のマークアップ時は
いわゆるアーキテクトリストアイテムとした
コンポーネント分割しかしないと思うように思ってますと。
この時点ではTLウィンドウを使わない場合
そのアーキテクトリストアイテムというコンポーネント内では
21:00
アーティクルタイトル、アーティクルサムネイル、
ユーザーネーム、ユーザーサムネイル、デートなど
名付けないといけないですね。
TLウィンドウならばこの時点では
しなくても別にいいですよね。
最初の一番スタイルをたくさん当てるタイミングで
命名の指向を最小限に抑え
レイアウトを組み込むだけに集中ができる
というのが嬉しいポイントその1であります。
もしコンポーネントを分割しなければ
命名していないということでもありますよ。
続いて嬉しいポイント2
命名の無駄を減らせるということですね。
またこのコンポーネントを分割するときも考えます。
例として他の場所でも使っているので
ユーザーアイコンとしてコンポーネントを
スクロールするとしましょう。
この時にユーザーサムネイルよりも
ユーザーアイコンの方が命名が適していると
思うかもしれません。
多くの場合たくさんのレイアウトが揃ってからの方が
正しい命名を付けることができます。
いわゆる俯瞰できるからということですね。
ここでユーザーアイコンと付ける命名コストは
テイルウィンドにかかるので
先延ばしと表現したが
クラスとして命名したユーザーサムネイルは
無駄になっていたと捉えることもできます。
先延ばししたことで命名コストを減らすことが
嬉しいポイント2であります。
無駄の削減ができたということですね。
嬉しいポイント3は
コンポーネント化しやすいということです。
クラス名が適切に命名されていた場合は
そこまで違いがない部分ですけど
前述したようにHTMLタグにスタイルを当てる人もいます。
例えばユーザーサムネイルが
以下に書かれていたとしましょうと。
CSSがガーって書いてあるんですけど
イメージっていうのがあって
アーティクルリストアイテムの下に
Libのラストチャイルドの下に
イメージっていうのを張って
そこでやっとスタイリングが当たると。
そんな書き方ですね。
コンポーネント分割にすべきHTMLと
CSSそれぞれ特定する必要があるんですけど
適切な命名がされていない
CSSの影響範囲の特定がやっぱり難しいと。
その点テイルウィンドさえ使っていれば
HTMLタグにスタイルを当てるっていう問題は
発生しないし
HTMLの場所さえ特定してしまえば
そこだけコンポーネントに移動すれば
完了であると。
まあまあまあ、確かにね。
別視点でテイルウィンドクラスが多すぎて
HTMLの特定をするのが難しいのでは?
って考える人もいるかもしれないけど
デベロッパーツールからクラスコピーし
丸ごとファイル内検索すれば
意外と簡単に想定できると。
なるほど、力技で検索しても別にできるじゃん
って話ですね。
これで探せない場合は
さすがに分化しなさすぎでは?
みたいなところはあると思います。
かもしくは
難しいですね。
そのためにわざわざクラス名つける意味は
やっぱりわからないですね。
それやったら最初からクラス振ってあげたほうが
楽だよねって感じですもんね。
はい。
想定した質問ですけど
スタイルコンポーネントが
インラインスタイルできますよね?
っていう風な主張もありますと。
実際その通りですけど
テイルウィンドの次に好きなものが
こうですという風に言ってます。
この秘書の方はテイルウィンドが好きで
その次にスタイルコンポーネントが
インラインスタイルの方が好きですよ
っておっしゃってますね。
はい。
しかし一度変数に入れて
HTMLに加える書き方も一般的であり
その場合はこの記事における
命名の先送りの嬉しさってのは
もうなくなってしまいますと。
この選択が存在する
制限できないことと
リアクト以外の相性の問題として
私個人はテイルウィンドが良いと感じています。
インラインスタイルは結構いいかもね
24:00
みたいなこと言ってますね。
はい。
最初からコンポーネント分割を
しっかり行えばいいんじゃないの?
って話ですけど
これもその通りだとは言ってます。
実はここまでの嬉しさは
私はやぐに的に
コンポーネント分割は
人になったタイミングで
した方が良いと考えている
という私の前提の上に
成り立っている意見ですよ。
はい。
で、うひょさんの元記事にも書かれてますけど
本当にTLウィンドを使っていたとしても
コンポーネント分割は
しっかり行った方が良いと
筆者は考えています。
一つのコンポーネントに属する
マークアップの塊がでかいというのが
一つの関数がでかいのと
同じ状態であり
通常それは望ましくありません。
より即物的な問題として
マークアップは
普通のプログラマに比べて
インデントが変動しやすい傾向にあり
スタイルが変更される際には
大胆に修正されやすいため
破壊的なコンフリクトを
破滅的なコンフリクトを
生み出しやすいです。
あらかじめコンポーネントで分割しよくで
破滅フラグを回避してください
という風におっしゃってますと。
こちらもTLウィンドを
使っていたとしても
コンポーネント分割は
しっかり行った方が良い
というのは同意ではあるんですけど
コンポーネント分割を最初から
しっかり行うことが
難しいと思っているので
このように思っていますと。
これもそうだと思いますね。
結果を作ってきた時に
見えてくるもので
いっぱいあるのでね。
システムはやっぱり
生き物だと思っていますので。
最後にもう一つ問いだけ。
デザインにこだわりがなく
最低限と整っていればいい場合と
逆にデザインシステムを
しっかり整備し
それからの逸脱を防ぎたい場合
それではない場合
どの場合で存在してよいのか
と考えた時に
ウェブ製作時くらいしか
思いつかないので
ウェブアプリケーションを
作る場合に
いつ存在するのか
を考えているところではあります。
そういった意味で
テイルウィンドクラス名なんて
絶対覚えたくないなど
テイルウィンドなら
ダメな理由がなければ
気軽に採用してほしいと
考えているので
この点は
元記事と私の考えは
違うかもしれません。
というところで
この記事は締められております。
はい。
まあまあ
こちらも結構共感とか
なるほどなって思うところも
ありましたね。
その命名を先送りにできる
嬉しさというのは
あるかもしれないです。
やっぱり未来を見ることが
僕らはできないので
そういう意味で
先送りにあえてする
というのは
一つの考え方ですね。
というところでした。
もちろん最初から
ちゃんと分割できれば
それはそれで
素晴らしいことであるんですけど
はい。
というところで
ちょっと時間が過ぎてしまったので
本当は
J3インフォの記事も
パッと読んでみたかったんですけど
30分来たので
今日はこちらで
終了にしたいかなと思います。
この2日間で
テイルウィンドは改めて
俯瞰的なご意見の
2つの記事を
読ませていただいたんですけど
やっぱり参考になるというか
勉強になったなと思いました。
自分がこう考えていない視点とか
ご意見というのが
見えたのがやっぱり
素晴らしいというか
ありがたいと思っているので
では
今日の朝活は
こちらで以上にしたいな
と思っております。
はい。
今日から月曜日また
また10月ですね。
はい。
今月
スタートは
今日からだって
方々も多いと思われますので
はい。
また今月も
しっかり頑張っていきたいと思います。
また
今月からまた
後半スタートっていう
会社さんも結構いると思いますね。
締め日が大体
3月の会社さんも
日本だと結構あるので
そういう時も含めて
後半
一発目から
しっかり頑張っていけたら
と思います。
ではまた明日も
のんびり読んでいきたいので
ご興味ある方は参加してください。
はい。
というわけで終了します。
お疲れ様でした。
