00:04
はい、おはようございます。
6月24日、月曜日ですね。
地獄は朝9時を回りました。
今日は東京めちゃめちゃいい日ですね。
今日も暑くなる日だそうです。
最高気温は37度以下らしいですからね。
はい、おはようございます。kkeethことくわはらです。
じゃあ、本日も朝活を始めていきたいかなと思います。
月曜日一発目ですね。
すごくちょっと昨日の夜、サーバーサブレンダリングのソースコードを書いていて、
なんかもう深夜なのに気になって仕方がなくて書き始めたら、
深夜3時半までソースコードを書いていたので、めっちゃ眠いですね。
おはようございます。
たくさんの方がいきなり参加したりですごくありがとうございます。
今日はですね、タイトルがありますね。
Notes on maintaining an internal React component library っていうところで、
今、React Componentのライブラリを作っている人たちがいて、
その人の知見であったりとか、設計思想みたいなところを書いてくださった記事があるので、
それをちょっと読んでいこうかなと思います。
Reactの記事ばっかり読むんじゃ遠くないっていう話はあるんですけども、
なんとなく読んでいこうと思います。
今回の記事はめちゃめちゃ長いので、多分何回かに分かれていくと思いますけども、
ゆるーくお付き合いいただければなというところです。
じゃあ早速入っていきましょう。
2021年11月からデジタルオーシャンの、デジタルオーシャンという会社ですかねこれは。
UIインフラストラクチャーチームに所属していますと。
UIインフラストラクチャーチームというのがあるんですね。
UIの設計構造だけのチームがあるんですね。
すごいな。
この秘書の方ですね、私の主な職務の一つというのは、
社内のReactコンポーネントライブラリであるウォラスっていうのがあるらしいですね。
の主要なメンテナーとして行動することです。
このライブラリは私が参加する数年前から存在しており、
以前のデザインの選択がどのように展開されたかを見るのはちょっと興味深いことです。
こちらのライブラリのドキュメントっていうのは、
多くのフロントエンドアプリケーションで使用されている既存のデザインシステムの一部として、
コンポーネントライブラリをメンテナーすることについての私の考えをまとめたものになります。
私はビジュアルデザインには実は特に興味なく、実装は得意ですけども。
ビジュアルデザインの実装は得意なんだけど興味ないらしいですね。
むしろ大規模なコンポーネントライブラリを構築する際の
ソフトエンジニアリングや社会的なチャレンジの方に興味がありますと。
今回のノートブログではさらに詳しい情報をお伝えしていきたいなと思っています。
じゃあ早速中入っていきましょうか。
最初のセクションはフィロソフィーですね。
フィロソフィーに行きましょう。
このようなライブラリをメンテナーする際、
私はインターフェースを通じて提供される微妙なインセンティブを理解しようと努めています。
もし開発者がレバーを引くことができれば、それは最終的に引かれることになります。
外国人の言い回しとか例えってちょっと難しいな。
03:03
収書度高くて難しいですね。
その開発者っていうのはチームの中で最も年長の人のある可能性もあります。
ブートキャンプから出たばっかりの人であることももちろんあります。
何十万行ものコードがあり、完成すべきタスクがあり、
正しいことを知るための必要なコンテキストが多すぎるのです。
状況とかは千差万別ですかね。
この問題は大規模なチームの力学から生まれ、どの組織にも存在します。
もしレバーが存在するならばそれは引っ張られます。
もうちょっといいんじゃないですかね。
It gets pulledって書いてるから直訳するとそうなるんでしょうね。
しかしその責任はレバーを見た開発者に全てかかっているわけではなくて、
それを提供した開発者にも責任があるのです。
良いデザインっていうのはライブラリーの消費者が成功の落とし穴に落ちる結果になる。
なる、あるって。
これはそういう記事がありますね。
Falling into the Pit of Successっていうのがありますね。
そういう記事があるのでそれを見てください。
ところですね。
成功の落とし穴っていうタイトルが結構面白いですね。
その良いデザインっていうのは果たしてただただ良いっていうかというわけではなさそうですね。
この結果を計測するには急がないで忍耐強く強い考察が必要になってくります。
一般的に言ってドキュメントに書かれていることは全て私が次のことを最大化することに決しますということですね。
大きく4つの話が挙げられていて。
1つ目ですね。デザインをUIコードに変更するのは簡単であるべきです。
いろんなチップスであったり小道具みたいなものはフィグマなどの設計システムやドキュメントに直感的マッピングできるようにしています。
コンポーネントはオーバーライドを適用しなくても正しく見えるようにしますというのが1つ目のフィロソフィーですね。
2つ目はコンポーネントというのはほとんどの場合それを消費する親に対して不透明なボックスとして動作する必要があります。
これそうですね。内部に関する詳細を漏らしていけませんし任意の構成スタイルを注入することも許されません。
データは中にマークアップは外にということですね。
なかなか面白いですね。
設計もしっかり分けるのとスコープを分けるのを意識しましょうということですね。
親がしっかり中身まで知って使うような感じの設計になっている。
要は依存度が高いのでそれは利用性が悪いよねって話だと思っています。
続いて3つ目ですね。
当たり前のことおよび簡単なこと正しいことっていうのはほとんどの場合重なり合うはずですと。
あーはいはいはいはい。
確かにそうかもしれないですね。
時間に追われていかない発車っていうのは通常最も簡単な回帰施策に手を伸ばそうとしています。
はい失礼しました。
すごく当てはまるのでなんとも言えないですね。
06:02
理想を言えば最も簡単な回帰施策は明白なものであることですと。
それは理想です。
そしてその当たり前のこととは私が開発者に最初にさせたかったことであるべきですと。
あーなるほどですね。
なるべくコンポーネントとか設計するときは明白にして分かりやすくしておきましょうということですね。
ラストのヒロソフィーとしては間違ったことをするのは少なくとも不快で最悪の場合不可能であるべきですと。
うーんなんかちょっと難しいですね言い方が。
Doing the wrong thing should be at least uncomfortable, at worst impossibleって言ってますね。
あーでも直訳するとそうなっちゃいますね。
最悪の場合そうですね。
はい、必要であれば逃げ道を用意して、しかし彼らもコンポーネントに嫌な思いをさせましょうと。
嫌な思いをさせましょうって面白い。
開発者は二度とこんなことはしなくて済むように石を開くべきだと思うはずです。
あーまあまあそういうことね。
なるほど。
これちょっとチームビルディングに近い思想かなって感じはしましたけど、なかなか面白い言い回しです。
あえて嫌な思いをさせようと。
もちろん逃げ道も用意してもいいですけど。
とはいえこのドキュメントに書かれているルールはどれも厳密なものではないですと。
それらはトレードオフの関係にあって、結局のところ私はスタイル上の柔軟性よりもデザインシステムの一貫性を優先していますと。
そのことを念頭に置きながらこのドキュメントを読み進めてくださいということでした。
ちょっと癖のありそうな人感が正直ここはありますけど。
最後に汎用的なオープンソースのコンポーネントライブラリーでは動機っていうか発端というところがやっぱり違うことになってくるので、
ここで挙げたトレードオフっていうのは必ずしも適用されるべきではないと思います。
もしかしたら適用されるかもしれないですけど、
本当にこれが必ずしも正しいというわけではないよという形ですね。
私の場合は今回作っているエルゼウォーラっていうのですね。
ライブラリーっていうのは私の会社のように見える必要があり、
コンポーネントライブラリーが私の会社のように見えることから逃れられることを望んでいませんと。
このライブラリーは我々の会社のものですよっていうふうな一つの顔として動いてもらうことを希望したいというか望んでいる感じですね。
でもやっぱり会社の名前を使って公にしているライブラリーなのでそれは素晴らしいかもしれないですね。
次のセクションです。
When everyone owns it, nobody owns itって言ってますね。
みんなが所有しているってことは逆に言うと誰も所有しなくなるってことになりますっていう意味ですね。
私の強い意見ですが、コンポーネントやライブラリーっていうのは誰かが所有しなければなりません。
所有者がいないとそのコンポーネントライブラリーっていうのはこれだけは必要だっていう単発の変更がどんどん蓄積されていて、
グループ化されたとしても設計システムの全体像を映し出すことはできません。
少なくとも一人の開発者はそのコンポーネントライブラリーのメンテナンスが仕事でなければなりません。
気持ちはわかるが僕としてはちょっともやった感じがしますね。
09:04
課題ってじゃあ明確にこの人っていうのがいなくなるとぐちゃぐちゃになったりカオスったりするのはよくある話なので、
メンテナンスチームがあったとしても最終的に温度を取る人は交代だとしても一人で決めとくってことがこの人にとっては重要だっていうふうな意見があると思いますね。
そこに関しては同意だと思います。
なるほどね。
続けていきましょうか。
例えばある製品、クリエイトエンジニアが実装しなければならない新しい設計を受けたとしましょうと。
その中には設計システムにはあるかもしれないがコンポーネントライブラリーにはまだ実装されていないコンポーネントのバリエーションが含まれているかもしれません。
この不完全性っていうのは大きな問題です。
なぜならそのエンジニアっていうのは自分たちが保守する責任のないコンポーネントライブラリに対して何かをしなければならないからです。
SNEのオーナーがいない場合、実装された開発者は解決策が通常簡単なこと、一般的には間違ったことになってしまいます。
いわゆる突貫作業になってしまいますよねみたいな話ですね。
これはよくある話だと思います。
コンポーネントを必要な分だけ更新しそれ以上のことはしない。
インターフェースに存在する様々な端末のプロプスを理解するためにしばしばコンポーネントの内部を検査しなければならないので将来の開発者の速度を低下させることになります。
まあそうねって感じですね。
必要なことだけをやってそれ以上のことはしない。
とにかく必要なときに必要だと思う人はやってくださいってことですね。
よくある話ですよね。
インターフェースに存在する端末のプロプスをどんどん理解するために中身をばーって見なきゃいけなくてそれは確かに開発者の速度を低下させるという事実ですよね。
続いてコンポーネントを更新せず、スタイルズコンポーネントなのでラップするみたいなこともあります。
このような変更がコンポーネントライブラリに戻ることはほとんどないため断片化を生み出します。
その経験は僕もすごくしましたね。
スタイルズコンポーネントは便利なんですけど、みんながみんな何か好き勝手にコンポーネント化したり、
結局似たようなやつを誰かが他の人も作ってプルリク出してて若干の名前の違いがあって結局どっち使うのみたいなのが荒れた瞬間にカオスですよね。
この話もよくある話です。
あとはゼロから別のものを実装するというところですね。
ライブラリに既に存在する可能性のあるエッジケースを考慮しないことが多い。
この辺も結構シュラパーくぐった感じの人だな。
これもすごく同意です。
このような解決策って結構複合的になりがちで、コンポーネントに変更を加える場合、既存のオーバーライドがビジュアルを壊す場所になる可能性があります。
そのために余計な注意も必要になってくるということですね。
そしてこのような状態が結構続いてしまうよということでした。
オーバーライドが増えれば増えるほど、スタイリスティックな変更を完全に安全に適応するのはリスクが高くなります。
12:04
いわゆる負の遺産というのが重なっていくということですね。
現在誰も所有していないコンポーネントライブラリがある会社で働いている人はこの痛みを感じていると確信しています。
TLDRとしてコンポーネントライブラリがクソなら誰かが職を失う必要が理想でなければおそらくクソになる。
急に親近感湧いてきたな、こういう汚い言葉を使うと。
私もあんまり出自が良くない人なので。
では続いてのセクションですね。
もうちょっと具体的な話に今後入っていきますね。
続いてですけども、ちょっとタイトル長いですね。
設計システムのバリエーションを簡潔に表現するコンポーネントインタフェースが使いやすいものである。
タイトル的にはアーコンポーネントインタフェース。
僕は英語読めないんですけど、コンシスリーですかね。
Representing the variants of the design system is easier to use。
私は設計書を読みながら全てのバリエーションをNG空間の軸のように可視化して、
各次元が一つのプロパティに相関しているかどうかを確認することにしています。
なんか数学的な人だな。
いわゆるデザインシステムのカラーだったりピッカーみたいなやつですけど、
あれのような表示の仕方をしていますね。
記事中には図があるんですけど、ボタンコンポーネント例とかをやって、
縦軸にプライマリ、セカンダリ、ターシャリーですかこれ。
横軸にディスエイブレットとかウィズアイコンみたいなのとかデフォルトみたいな感じで、
縦軸と横軸でパターンとかのバリエーションを見ているという感じですね。
もうちょっと記事入ってきます。
どの視覚的差異が独立して動作し、どの視覚的差異が独立して動作しないかを理解することが結構慣用です。
例えばボタンのタイプとディスエイブレットのプロプスっていうのは互いに独立しています。
直行しているっていうことも言えるかもしれないですね。
デザイナーとしてはできればセカンダリボタンを無効にすることはできないと提案することはないでしょう。
この2つは確かに直行していると思いますね。
タイプとディスエイブレットですね。
タイプっていうのはさっき言ったプライマリ、セカンダリなんちゃらみたいなことですけど。
で、ソースコードが若干出てきて、タイププロプスとエクスポートボタンでリアクトFCみたいな感じだって書いてますけど。
タイププロプスの方の型定義としてタイプ、今回はオプショナルですね。
このコロンでプライマリ、セカンダリ、ダーシャリと。
ディスエイブレットがブリアンで、アイコンもアイコンっていう型ですね。
が渡されるようになります。
で、この場合、それがさっきの話ですね。
逆にですね、互いに依存し合う差分っていうのは単一のプロップに統合して、
その単一のプロプスは独自の次元として動作させる必要がありますと言ってますね。
例えばオプションでラベルを持つテキストインプットでは、ラベルはオプションでツールチップを持つことができます。
15:03
あー、はいはいはい、なるほどね。
それも確かにいいかもしれないですね。
はいはい。
まあそういうものは基本的には独立じゃなくて、
統一をして一つのプロプスとして渡してあげるのがいいんじゃないかということですね。
これは確かに納得はしますね。
はい、では続いて。
ラベルがないとツールチップが表示されないので、
インターフェースにラベルとラベルツールチップみたいな2つのプロプスがあるのはぶっちゃけ意味がないと。
なぜならツールチップはラベルなしで表示されないからですね。
この要件を満たすためにそれらは単一のプロップに混ぜされるべきですと。
そういうことですね。
プロプスとしてオブジェクトとしては、
ラベルとラベルツールチップでふたり渡すこともぶっちゃけ意味がなくて、
ぶっちゃけラベルでいいじゃんって話ですね。
そのツールチップに出すものはその他のラベルなんでということです。
はい。
次の型定義ですけど、
type props="label-optional-colon-string="
というのはよくなくて、
type props="label-non-optional="ですね。
ラベルのオプショナルですね。
コロンのストリングまたはテキストの
ストリングツールチップみたいな感じで。
普通にあるか。
プロプスとしてもオプショナルで
複数個渡しても別にいいんじゃないって感じですね。
なるほどです。
テキストインプットのコンポーネントではそれを受け取って、
型定義をセットしてあげて、
渡すプロプスは一つでも一応オブジェクトにして渡してあげてもいいということですね。
はい。
ちょっとうちの家のネットワークが遅くて、
なかなか翻訳が遅いんですけど。
あ、来ましたね。
今見た型定義ですけど、
このタイピングっていうのは私がずっと好きだった
プログラミングのイズム、プログラミングイズムか。
の一つを抱負とさせますと。
どういうものかっていうと、
違法な状態を表現できないようにするっていう
その思想ですね。
に似てるなってことでした。
ちなみにこの違法ななんちゃらかんちゃらっていうところに対しても
記事がリンクを貼ってあるんでそこも
見てほしいなっていうことだそうですね、これは。
はい。
Take Illegal States as Unrepresentable
っていうタイトルです。
はい。
もしデザインシステムが全ての可能な
合法的な視覚的状態っていうのを
表現していることを仮定するならば、
チップス的なものは
違法な視覚的状態を許すべきじゃないよ
って言ってます。
合法的な視覚的状態っていうのが
既にもうちょっと僕はよくわからない。
Legal Visual Statesって書いてますけど。
そういういろんな思想とかルールにのっとった状態を
表現していると仮定するならば、
そんないろんな小道具っていうのは
違法な視覚的状態を許すべきではないと。
それはそうかもね。
はい。
ラベルがなければ
コンポーネントはツールチップを表現しないので
プレゼンテーションは有効なままだと
主張する人がいるかもしれません。
ラベルがなければ
コンポーネントはツールチップを表示しないので
プレゼンテーションは有効なままだと
18:00
主張する人がいるかもしれんけど
さらに誰かが実行時のチェックを追加して
不変性を強制することもできますと。
はい。
しかしなぜ実行時まで待つ必要があるんでしょうかと。
なぜ他の開発者が混乱するのを待つんでしょうか。
はい。
この怠惰っていうのは
正しさの責任を開発者、
そしてその後のすべての開発者に
押し付けることになりますと。
はい。
タイプチェッカーによると
テキストインプットスペースラベルツールチップ
イコールビックリみたいなものっていうのは
完全に有効ですと。
このコードにはラベルなしでツールチップが
存在できないという暗黙のルールがあって
このコードのコントローリングっていう風に
明確に示されていますと。
それはそうです。
で、最も極端なケースでは
リダックスのリデューサーが
アクションドットタイプで
切り替えるのと同じように
コンポーネントが単一のキーで切り替える
プロップインターフェース必要するかもしれません。
このようなシナリオでは
代わりにいくつかの異なるコンポーネントを
作成する方が理にかなっています。
おそらく共通の内部ベースのコンポーネントを
使うことになると思いますが。
はい。
これも確かに理にかなっていますね。
これは極端な例ですね。
でも確かに。
リデューサーのアクションタイプで
切り替えるっていうのと似たように
コンポーネントが単一のキーで切り替える
プロップインターフェースが必要する状況になるんだったら
コンポーネントそのもので切り出しても
別にいいかもしれないですね。
はい。
なるほどな。
でもツールチップレベルだったら
そこまで切り替えることはないと思いますし
先ほど指定してあったように
プロップスは一つとして受け取って
ツールチップとテキストを
2つで受け取るかみたいなところですね。
という風に型を定義してあげる方が
いいんじゃないかなというところがありますね。
はい。
では続きまして、
まじか。
長いなこの記事。
次のセクションは
コンポーネントはおそらく
位置決めをしちゃいけないでしょうと。
まあそうね。
コンポーネントそのものが
位置を決めては多分いけないと思います。
はい。
以下の画像を見てみましょうと。
以下の画像をちょっと口頭で説明しますと
でっかい
AというコンポーネントとBというコンポーネントが
今横並びになっていて
Bのコンポーネントの左に
余白、これ多分マージンかな?
が入っているように思います。
で、それを包む大きいCというコンポーネントが
あるみたいなイメージを持ってください。
で、AとBの高さは一緒です。
で、AとBの
Bの方が
ウィッズが長いですね。
Aの方が横幅が短くて
Bの方が横幅が長い。
縦幅は一緒です。
で、それを包むCのコンポーネントは
単純にもともと大きいですね。
縦も横も長いって感じです。
こんなような状態を考えてみましょうと。
で、Aに属する場合の結果を
マージンライトとして一旦考えてみますと。
Aコンポーネントの右に
21:00
余白を付けてみましょうと。
つまりスペーシングはAの内部で行われます。
これを行う際の問題は
Aのデフォルトのプレゼンテーションが
マージンライトを含んでいることです。
そうすると下の画像ではどうなるでしょうか。
下の画像はですね。
今度はAのコンポーネントと
Dのコンポーネントがあって
さっきとは違って
AとDの間に余白はないですね。
それを包む大きいEという
コンポーネントがありますね。
で、今回はEがあって
AはDの横に表示されますけど
スペーシングはありませんと。
こういう場合ですね。
まあまあ言いたいことは何だか
わかりますけど。
Aの内部的なマージンライトがある場合ですね。
先ほどのように。
それをC0に上書きする必要がありますと。
これはスタイルのルールというのを
ブラウザのデフォルト値に
効果的に戻すことになりますと。
このような手順を踏むことは
コードの匂いのような感じになります。
まあまあそうね。
わざわざつけたものは
あえて消しにいくということですよね。
この問題を回避する一般的な方法というのは
コンポーネント自身が外側に
マージン、つまり余白というものを
適用すべきではないということですよね。
要は余白とかっていうのは
それを利用する親の方で
余白調整をしてあげて
コンポーネント単体で
余白をつけないような話ですね。
この辺はしっかりと言いますね。
では続いて。
コンポーネントは通常当たられた
水平方向のスペースを
すべて使用する必要があります。
ほとんどの場合
コンポーネントは親が与えた幅を
すべて所有するはずです。
その場合は
コンポーネントは親が与えた幅を
すべて所有するはずですと。
占有するはずですね。
つまりほとんどのコンポーネントの
デフォルトの状態というのは
中に入っている何かの幅を
すべて取るということです。
コンポーネントがページの幅全体を
閉めていない場合
通常はコンテナ、フレックスだったり
グリッドだったりスペーサーなどの中で
表示されていて
コンテナが制約を与えていることが
原因になります。
それもそう。
余白はフレックスボックスの
コンテナでちゃんと
管理しているという感じになります。
このルールを適用すると
ほぼすべてのメディアクエリの
CSSというのがコンテナコンポーネントですね。
フレックス、グリッド、スペーサーなどの中に
あるべき場所に存在できるので
レスポンシブページの
実装が容易になるということです。
ちゃんとページの横幅一杯は
全部コンテナで管理できている方が
レスポンシブ対応できるので
いいですよって話ですね。
コンポーネントが配置している
場所はその都度
余ったから余白みたいな
文字通り余白ですけど
にしないでその幅自体は
ちゃんと管理しましょうということですね。
続きまして
ここからチップス的な話が
どんどん増えてきましたね。
最初の方の設計思想というところが
思想感があったり
ちょっと難しかったんですけど。
続いてコンポーネントは
24:01
プロバブリーシューティングと
エクスポーズクラスネームは
スタイルプロップということですね。
クラスネームとスタイルっていうのは
コンポーネントのスタイル的な
カプセル化を破壊します。
これらの属性によって
誰かが気まぐれに任意のスタイルを
上書きすることができちゃうんですね。
このハックっていうのは
設計システムの仕様が
既に実装に存在する場合には
おそらく望むところじゃないよと。
理想的なシナリオでは
親コンポーネントは
個コンポーネントを不透明な箱とみなして
非常に特定なレバーを引くようにします。
全てのレバーは引かれるからです。
基本的にプレゼンテーションを
変更することができない
あるいはその必要がないはずですと。
なるほどね。
クラスネーム、スタイリングもそうです。
基本的にはそうだよ。
スタイリングを外から書き換えられたら
ちょっとめんどくさいですから。
要はちゃんとスコープ切って
カプセル化をしましょうって話ですかね。
それのもうちょっと似たような話が
次に出てきますね。
次のセクションは
If we must offer an escape hatch
for custom style overrides,
it's better to expose them up.
unsafe underbar class name
and unsafe underbar style
もしカスタムスタイルの
オーバーライブドのための
逃げ道を提供しなければならないのであれば
unsafe class nameとか
unsafe styleみたいなものを付けて
それを公開するのがよいでしょう。
とにかくスタイルの浮気は絶対にダメだ
というふうに強い主張をされてますね。
No style overrides everって書いてます。
と主張するのは全く合理的ではありませんが
失礼しました。
そういう意味ではなかったです。
スタイルの浮気が100%ダメってわけじゃないけど
かつそれは合理的じゃない。
もしエスケープハッチが必要であれば
それを行うことは恐ろしいことであって
グレップするのは簡単であるべきです。
私が友人から盗んだソリューションっていうのは
これらのプロプスの両方に
unsafeという設定を付けることです。
そういう発表をすると
こうしてる人がいるんですね。
Nothing to see hereということで
一つ目の悪い方の例としては
ボタンコンポーネントっていうのが定義されていて
class name equal abcみたいな
クラスネームが付与されています。
こういうのは良くなくて
ボタンコンポーネントのプロプスに
unsafe underbar class name equal abc
みたいなふうに付ける。
今言ったやつですね。
しかもunsafeってこれ全部大文字ですね。
大文字のunsafe underbar class name
とかに付けるほうがいいんじゃないの
って話をしてますね。
なるほどです。
でもfeelisterrible
looksgross
easytogrepって言ってますね。
見た目はキモいけどグレップはしやすいと。
なるほどですね。
クラスネームっていうのは
スタイルコンポーネントのようなライブラリーが
任意のスタイルを注入するためのフックであると。
クラスネームをunsafeクラスネームを
置き換えることで
27:01
スタイルコンポーネントで何かを進むという誘惑を
私はこれを大きな勝利と見ています。
本来のクラスネームっていうのは
そういうふうにライブラリーとかが
そこをフックするための
注入されるためのフックになっているんです。
今はね。
なるほどでした。
またリンタールートルとか
オーバーライドの過剰な使用を防ぐための
別のツールの扉を開くことがありますと。
このチェックはクラスネームでは不可能でしょうと。
まあそうかね。
これでも面白いですね。
なるほどです。
名前も明示的にunsafeっていうのを
分かりやすくていいですね。
はい。
続きまして
次のセクションは
一般に基本要素のプロップスからの
拡張を避けるようにしましょうと。
Generally try to avoid
extending from base element props
ということですね。
リアクト.html
attributesの
htmlボタンエレメントのような
ベースタイプからの拡張っていうのは
コンポーネントのインターフェースを
使って拡張することになります。
私が調べたところでは
これを行う場合
恐らくコンポーネント
かっこボタン内の
何らかのベース要素に
それらを全て転送しようとしている
ということです。
言いたいことがあってきました。
インターフェースでプロップスがあって
extend react.html attributesで
genericsでhtmlボタンエレメント
っていうのを定義していて
中身はタイプでオプションなんですね。
文字列が基本的に定義されていて
それを実際に使うときは
ボタンコンポーネントの
react.fcのプロップスで
型定義しておいて
引き数にプロップスを受け取って
そこからタイプ、ディセーブルで
アイコンなちらかんちらで
あとドットドットレストですね。
受け取りましょう。
リターンでボタンコンポーネントの
プロップスとしてさっきのレストを
オブジェクト展開しているって感じですね。
数が増えれば増えるほど
この辺どんどんバーッと
渡されていくってことですけども。
これを構築するときは
私はそれが許可する編集について
非常に明確にしたいと言っています。
クラス名やスタイルプロップが
不要か、などと同じ理由で
ベースからの拡張を可能にしたくありません。
恣意的な改変の可能性があるからです。
ここに関しては
ベースの拡張をあるべくしたくはない
ということですね。
インターフェースが明確になってある
っていうのはすごく正しいですし
いいことだった。
そういうものを入れ込みたくない
っていうのがあったのが
根本思想にありそうですね。
だからベースの拡張したくない
というふうに言っているような気がします。
もしくはそれにエクステンズしてるんであれば
エクステンズをさらにエクステンズする
という闇もあったりはしますけど
それも避けたいってことでしょうね。
30:01
どうしようかな。
気づいたらもう30分過ぎてましたね。
今ここまで来て半分まで来ましたね。
半分まで来たのと
これちゃんとこの人の思想を読みながら
読んでいかないと理解がしづらいので
今日適当に読んだのは
やっぱり適当すぎたので反省してます。
明日はまた次回
この続きを読んでいこうと思いますけど
もうちょっと先にある程度読んでから
明日はここの続きを読んでいこうかなと思います。
そして明日はソースコードが
結構バーッと出てくるんで
それこそ理解をしていかなきゃいけないと思うし
事前知識がないといけないので
最初に冒頭で前提知識を
ちょっと語ろうかなと思います。
じゃあ一旦今日の朝勝は
この辺で以上にしたいと思います。
文字通りだらだら読む回だったんですけど
たくさんの方ご参加いただきありがとうございました。
明日はこの続き
リアクトの設計の話を読んでいこうかなと思います。
では今日からまた1週間ですね。
月曜日頑張っていければなと思います。
じゃあお疲れ様です。
