00:07
6月28日、遅刻はアタック城もありました。
火曜日ですね。
はい、今日も東京もすごく暑くですね。
なんかニットを見ると、イントより暑いとか言う噂らしいですね。
はい、まだ6月なのにこの炎天下、大変だなって感じです。
はい、おはようございます。ひめみのきーすかとくわはらです。
では本日もまた朝活を始めていきたいなと思います。
はい、前回に引き続き、前回も昨日ですね、引き続き、
今回も、Notes on maintaining an internal React component libraryっていうタイトルの記事を、
まあ続き読んでいこうかなと思います。
昨日で前半読み終わったので、今日も後半だと言っていこうかなと思います。
はい、まさきおらしくですね。おはようございます。ご参加ありがとうございます。
今日も記事をダラダラと読んでいこうかなと思ってます。
はい、じゃあ早速入っていきましょう。
今日は、Avoiding JSX Spread on Falling Data Prevents Wire Bugs Sometimesということですね。
そこから入っていきたいと思います。
はい、要は外部データに対するJSXのスプレッドフォームを避けることで、
時々変なバグを防いでますよって言ってます。
はい、要はですね、外部データを扱うときに、スプレッドエンザーシステムを一切使わないようにしているそうですね、この方は。
はい、とあるコンポーネントから別のコンポーネントにプロプスでデータを出すんですけど、
それが覆われている、ブランケットされているっていうようなことをしたくないってことでしたね。
はい、外部データに対してスプレッドを使用すると、いくつかの欠点もありますよってことをおっしゃってます。
はい、一つ目に特定のプロプスがどっから来るのかが不明確になる可能性がありますと。
いわゆるそれによってグレッピングがうまく機能しないよってことをおっしゃってますね。
はい、すみません、失礼しました。
これはあれですね、プロプスっていうかコンポーネントが結構ネストする場合とかの話ですね、これは。
ReactとかUseContextとか使ったらいいかもしれないですけど、それでもやっぱりグリップ機能がうまく機能しなかったりするので、
あんまりスプレッドコーブを使わないようにこの方はしているっていうことでしたね。
で、二つ目のところですね。
二つ目の理由は、意図しないプロプスを渡してしまう可能性があるよっていうふうに言ってました。
TypeScriptはこれを補足してくれないので、ここが結構また課題になってますよって言ってましたね。
この方はじゃあどうするのかっていう話をしてますけども、
可能な限りプロプスのオブジェクトを分解して必要に応じてキーを転送することをお勧めしますと。
この値とかこのデータですよっていうのを明示的に渡してあげるっていうのが、
一応この人の会議スタッフになってますと。
プロプスを分解することで過剰なキーを削除して、
デフォルトを設定できるようになればコードのグリッピングが結構容易になりますよってことでした。
まるっとオブジェクトをスプレッド演算してまで渡すんではなくて、
03:04
ちゃんと分解をしてこれこれこれっていうふうに見ていくってことですね。
ちょっと面倒くさいというか手続きが増えるかもしれないですけど、
それでも分かりやすさというか、
意図しないことを避けるって意味の方がこの人たちは重要なんだなってことですね。
続きまして、
ココンポーネントのいわゆるパススルーのプロプスを制限する方がうまくいくよっていう風に言ってますね。
例えばですけど最大2つのボタンを持つモーダル型として、
そのコンポーネントに対してモーダルは一般的なものに、
ボタンは完全なプロプスでカスタマイズできるようにしたいと思うかもしれませんと。
そうですよね。
モーダルを共通化してボタンとかを完全にプロプスとかでカスタマイズできるようにするってよくある話ですね。
でこれに対して、
今回はちなみにプロプスとしてプライマリーボタンとかセカンダリーボタンとか
そんな感じで渡しますねってことですね。
これはアプリが一般的に使われない基本レベルの内部モーダルコンポーネントでは問題ないと思います。
しかし同じプライマリーボタンプロプスとか、
でも全ての呼び出し場所にある場合、
プライマリーボタンプロプスブログが全ての呼び出し場所にある場合、
一貫性がなくなりますよと言ってますね。
ブログって言ってるのはJavaScriptのオブジェクトのブログですね。
全ての呼び出し場所にある場合、一貫性がなくなります。
全てにあるんだったら一貫してるんじゃないのかこれ。
どういうことだろう。
さらに全てのボタンプロプスを明示的に呼び出すとボタンに関する詳細が親コンポーネントに漏れてしまいます。
それは確かにそうですね。
基本的にこの方はコンポーネントはちゃんとスコープを切って、
中身までしっかり知らなくてもよく使えるようにしたいっていうのが確かしそうにあったと思うので、
そこに関してはあんまり嬉しくはないと。
ただ同じプライマリーボタンプロプスを、
プロプスのプログか。
全ての呼び出し場所にあると一貫性がなくなる。
これどういう意味なんだろう。
コード的にもすごいシンプルすぎるコードなのでちょっとわからなかった。
もうちょっと読んでいきますね。
その代わりにモーダルには様々な視覚状態を表すバリエーションが必要になりますよと。
例えばボタンプロプスですね。
現在はアクションみたいなプロプという名前になってますけど、
そういう場合には一般にインスタンス間で合理的に変化させることができる少数のものに限定されるべきですと言ってますね。
型定義もタイプとDisabledとプライマリーアクションプロプスみたいなのを足してますね。
06:03
あとはセカンダリーアクションプロプというものに限定しておくと。
ここはもうちょっと具体的にモーダルコンポーネントのソースコードの例が見たかった。
型定義しかないのであんまりイメージできなかった。
よくやるパターンだなと思ったので。
続きを見ますね。
私の意見ではこの制御をモーダルに移動させる改善になるようと言ってますね。
制御自体をモーダルに移動させるようになるというのが一つの意見ですよ。
将来的には情報というもののモーダルのセカンダリアクションというのはボタンではなくてリンクっぽいコンポーネントにすると決めるかもしれません。
前者の場合これはもはやかなりの破壊力を持つ変更です。
制御自体をモーダルに移動させるというのは結構大きい変更になりますね。
しかし重要なのはこの新しいインターフェースではこのような詳細はモーダルの内部に置けられることです。
だから結局はスコープとセキムというのをしっかりそこに渡して閉じてしまいたいということですね。
アクションが今後もしかしたらボタンではなくてリンクになるかもしれないし、リンクコンポーネントをそこに配置するようになるかもしれないですけど、
基本的にはどうやろうともセキムはそこにしっかり閉じておくというところを重きを置いているということですね。
その中でチャイルドコンポーネントのプロプスというのをしっかり制御していくのがいいんじゃないかという話をしているっぽいですね。
いわゆる規定クラスじゃなくて、ベースとなるモーダルコンポーネントを作る場合としても一貫性を保ちたい場合は何でもかんでもプロプスを渡したらいいというわけではないですし、
そこの制御をしっかりしてくださいねということでした。
では続きまして。
Most of the time it's a good idea to use React contexts for components that depend on each other.
大抵の場合、互いに依存し合うコンポーネントにはReact contextsを使うのが良いでしょうと。
ここはタイトル通り分かりやすいです。
私の理解ではコンテキストの本来の使用目的というのは至る所にプロプスをスレッド化することなく依存するコンポーネントのデータをリンクすることです。
この辺は多分皆さんの認識が一致していると思いますね。
例えば、今これ下側にソースコードの例があるんですけど、
セレクトメニューってものとセレクトオプションのカスタムコンポーネントを作ってみましょうと。
コンテキストを使用しないと全てのオプションに同じセレクトハンドラーとセレクティッドブーリアンをつなげばならないと。
今回はセレクトメニューとセレクトオプションというコンポーネントがあって、
それを使った別のなんちゃらみたいな関数コンポーネントを作ってますね。
09:04
とりあえずのユーズステイトで初期値にセレクティッド、セットセレクティッドみたいな関数を作っておいて、
リターンにその中のセレクトメニューとそれにネストしたセレクトオプションが1,2,3,4,5みたいな感じで並んでいるっていうようなイメージです。
それぞれに対して値をどんどんバケツ入れをし始めますよみたいなことを書いてますね。
これをコンテキストを使用すると各セレクトオプションに現在選択されているかどうかを示す必要というのはもともとなくなって、
現在選択されている値をセレクトメニューで伝えることができますよということですね。
これもそうですね。
コンテキストを使えばそのまま意思表示というか状態がはっきりするので、それを使えばいいんじゃないのってことですね。
オプションに対してはオプションをただただ置いておくだけで、
セレクトメニュー自体にデータを出すだけで良くなるし、それでもいいんじゃないのって話をしてますね。
ここはちょっとコンポーネントはそもそもデータ渡しの設計の話も出てきますけど、この例ではですね。
もう一つですね。コンテキストというのはライブラリーの内部で保持するべきですと言ってますね。
そのコンテキストをインポートしてアプリケーションで扱えるようにすると将来のアップグレードで簡単に壊れてしまうような脆い結合になってしまうので、
基本的には内部で保持しておくことがいいですよという風に言ってますね。
なるほどでした。
とかくユーズコンテキストってとりあえずどこでも使えちゃうし、
とりあえずコンポーネントにデータをバンバン渡すというのは確かに便利ではあるんですけど、
要法要領を守らないと今後の変更であったりとかに対して壊れちゃう可能性があるよってことを言ってますね。
そもそもコンテキストを使わなくていいパターンもあったりしますしね。
NEST何階層までいったらユーズコンテキストを使うかっていう話はありますし。
わかりやすく素直にバケツ入力をするっていう、あえて振り切ってるようなプロジェクトもあったりは気にしますね。
外で勉強会で言ったときにそういう話を聞いて逆転してて面白いなと思いました。
ただフローとしてはわかりやすいし、飛び道具って意味ではないので、
明示的ではあるなと思いましたね。検索性は悪いですけど。
はい、というとこです。
続きましてグルーピングのロジカルコンポーネントは、 シングルオブジェクトはほとんどゼロコストコンビニエンスですね。
論理的なコンポーネントを単一のオブジェクトとしてグループ化するっていうことは、 ほとんどゼロコストで済む便利な方法ですよと。
例えば先ほどが出てきているセレクトメニューというものと、 その子供になるセレクトオプションというコンポーネントが一緒にエクスポートされるのは別にいいことなんですけど、
コンテキスト上一緒にレンダリングしなければならないから、 そういうふうにしてるんだって。
12:00
このように常に一緒であることはデータの塊であるため、 それらを単一のオブジェクトにグループ化をしていますと。
例えば、セレクトっていう一つのオブジェクトがあって、 それに対してセレクトオプションっていうのを渡して一つのオブジェクトを作って、
それをエクスポートしちゃってるって感じですね。
何らかのインスタンスの方、別のコンポーネントの方で、 その先ほど作ったラップしたオブジェクトをインポートをして、
インポートした名前.メニューとか名前.オプションとかでコンポーネントに、 JSXに渡していく感じですね。
やったことないですね、これ、確かに。
確かに一つの塊っていうふうに名刺になるので分かりやすいし、 データもそこで集約されるので、そういう意味では確かにいいかもしれないですね。
ちょっとやったことないですけど。
なるほど。要は依存する、強い依存があるコンポーネント同士を 一つのオブジェクト化してエクスポートをするってことですね。
確かにこれはゼロコストで簡単にやれるものですし。
考えたことなかったな。そっか。
お互いで確かに使ったら依存し合うんで、 データもそこに集約するのが絶対いいと思うので、
コンポーネントに分けたものを作っておくのは 全然いい話なんですけど、
それを使うときにはちゃんとまとめちゃうっていう、 グループ化するっていうのは確かに僕はこれいいなと思いました。
逆に他の人が使うときもあっという間に これは一緒に使うものなんだなっていうのが明示化されるので、
他の人とかチーム開発にする意味でも、 ちゃんと意図とか意思が分かりやすくなるので、
これは大賛成ですね。
なるほどでした。勉強になるな。
続きまして、
It's a good idea to avoid rolling my own headless abstractions for browser APIs.
なるほど。
ブラウザーAPIのためのヘッドレス的な抽象化を 自分で作られないようにするっていうのが
いいアイデアだよっていうふうに言ってます。
どういうことかというと、
JavaScriptでブラウザーAPIを叩くときですね。
通常、車輪の再発明を試みるべきではない。
日本語がおかしいな、これ。
JavaScriptブラウザーAPIは通常、 車輪の再発明を試みるべきではない。
要はJSのブラウザーAPIですね。
車輪の発明を要はするべきじゃないっていう話を よくされますけど、
要はすることはなんだかんだ微妙だよねっていう話だと思いますね。
性能に優れてエッジゲースを取り除いて
ヘッドレス抽象化に頼ったほうがいいでしょう っていうふうに言ってますね。
私は以前、必要なのは20行のコードだけだと思っていた。
強いな、20行のコードか。
15:02
って思っていたんですけど、
それがパフォーマリーで動かないみたいなバグ報告を受ける
っていうトラブルに見舞われたことがあると。
私のようにならないようにしてくださいねって言ってました。
そんな、なかなか20行に絞るみたいなことは そんなしないと思いますけどね。
なんだっけ、プログラミングの格言的なものに 確かあってた気がします。
20行だったかな、24行だった気がしますね。
24行ルールみたいな記憶がありますね。
関数とかメソッドを最大24行までに絞りましょう みたいなのをどっかで見た気がします。
Rubyかな?
そういうことをしていくと 他のところで動かなかったりするので、
基本的にはエッジゲースの取り除いといった ヘッドレスな抽象化に飛び込むのがいいんじゃないの?
っていう風に言ってますね。
ここはなんか皆さん普通にやってそうな気がしますし、
この方が特殊なケースだと思いますね。
なかなか面白いな、20行。
続きまして、
メジャーバージョンアップで非推奨のものだけを 出荷するっていうのはあんまりストレスが少なくていいんじゃないの?
っていう話をしてますね。
非推奨のものだけを出荷する?
シッピングですもんね。
シッピングオンリーディプリケーションズなので、
非推奨のものだけをシップしてしまうっていうのが 結構ステラストレスですね。
ちょっとコンテキストの話をすると、
今回の記事を書いている方がウォラスっていう ライブラリーを作っている会社ですね。
そのライブラリーの名前が今回出てるって感じです。
ウォラスっていうものは内部パッケージレジストリに 公開されているので、
多くのフロントエンドアプリケーションにまたがる ことも一応しております。
ウォラスっていうものは内部パッケージレジストリに 公開されているので、
多くのフロントエンドアプリケーションにまたがる ことも一応しております。
内部パッケージレジストリに公開されているので、
多くのフロントエンドアプリケーションにまたがる ことも一応できますよと。
また、ウォラスの更新は結構面倒で、 製品チームにとって障害にはなりますよと。
アプリケーションがやっぱり数番上、 数バージョン遅れていても、
チケットが最新のものを要求している場合は、 アップグレードの一環としてのブレイクチェンジですね。
破壊的変更っていうのはブレイクによって とてもつもない障害になり得ますと言ってますね。
そうですね。数バージョン遅れているんだったら そりゃそうでしょう。
その代わりに、我々は例えばエンバーのような バージョン管理モデルに従って、
メジャーバージョンアップでAPI、プロップ、 ヘルパーズなどを非推奨にしているそうですね。
非推奨の95%以上を修正するために、 一つまた多くのコードモスを含んでいますと。
変わったやり方だな。
そしてそのエンバーのような バージョン管理モデルってちょっと気になりますね。
これ全然エンバーのリポジトリとか見たことないし、
エンバーの開発チームのブログとかも 読んだことがないので、
ちょっと気になりますね。
この方法だとチームはウォーラースを すぐにアップグレードできて、
作業の準備が整うまでうるさいコンソールに 悩まされるだけです。
18:03
コンソールに悩まされるのは確かにそうですね。
僕らは多分コンソールログで デバッグをしていくのでそりゃそうですけど。
なるほど。
はい、というところでした。
なるほどですね。
非推奨のものだけを切り出すか。
コアなのはやっぱりさっきも言ったとおり、
エンバーのバージョン管理モデル っていうのが結構コアっぽいですね。
それの思想とかコンセプトに従って メジャーバージョンアップで
APIとかプロップとかヘルプバージョンなどを 結構非推奨化していて、
それを修正するためにコードモードっていうのを 含んでるって言ってますからね。
ここはちょっとリンクとか貼って 欲しかったなっていうのを思いつつ、
海外では結構有名なのかな。
僕がちょっと不勉強だったので 大変申し訳ないですけど。
こういうことをすることで アップグレードが結構簡単にできて、
作業もそうまでは基本的に、
コンソールでうるさく言われますけど、
それ以外は基本的に問題ないよって 言ってるんで。
はい、じゃあ続いていきましょう。
続きましては、
ちょいちょい出てきたコードモードってやつですね。
コードモード、Made me faster。
かっこしてAfter I became a good at コードモードって 言ってますね。
例えばコードモードっていうのは 果たした我々より早くしましたよと。
得意になっているから早くなったって言ってますね。
慣れるまで多分遅いと思いますけど。
我々がいる特定の状況では そのコードモードを書くことで、
すべてのコードベースに当たる重要な変更を 迅速に出荷できるようになりましたよと。
先ほども出てきましたけど、
非推奨を含むウォーラスのバージョンには、
通常その非推奨を修正するための コードモードがあります。
このコードモードっていうのを使用すると、
問題のあるコードがアプリケーションが 削除される前に、
チームが非推奨のメッセージを見ることさえ ないことがよくあると。
はい、なるほど。
どういう感じになるのかな、 そのコードモードっていうのは。
気になりますね。
コードモード自体のリンクは貼ってあって、
時間の関係上読むのは多分不可能だと思いますが、
リンク先はこれあれですね。
Facebook社のリポジトリで、
JSCodeShiftっていうリポジトリがあるんで、 それのことを言ってますね。
もちろんこれNPMで インストールできるものなんですけど、
あとはVS Codeでバッグ側も入ったりする、 あるらしいですね。
要はこれは何かというとツールキットです。
Over Multiple JavaScript or TypeScript Filesっていうところですね。
複数のJSやTSファイルを今違ったコードモードを 走らせることができるツールキットですよと言ってますね。
名前だけは実は知れたんですけど、 ちゃんと使ったことはなくて、
コードモードはあんまり意識したことがなかったんで。
改めて今回記事読んだし、
見てみたいに使ってみようかなと思いました。
21:05
では続いていきましょう。 残り10分切ってますね。
続いてですね、
Idempotentのコードモードっていうのは、
A lot less stressfulですか。
べきじょう、べきじょうね。
べきじょうのコードモードっていうのは はるかにストレスが少ないですよと言ってますね。
私はコードモードがべきじょうであることを 確認しています。
開発者が同じモジュールに対して 何度も実行するコードモードっていうのは、
開発者が一度だけ実行した場合と 同じ結果になるようにしています。
適当性を保っているということですね。
この追加要件っていうのは、 コードモードが複数回実行されても
エラーを引き起こさないようにするためですと 言ってますね。
なるほどですね。
ここから、
なんか具体的な話がいっぱい出てきますね。
何度もっていうところに結構重きを置いてるっぽいですね。
なぜ複数回実行するんでしょうか。
次のようなシナリオをちょっと考えていきましょうと。
シナリオ5パターンありますね。
1つ目はコードモードが実行されて、
その結果がメインブランチに マージされるっていうケースですね。
2つ目には、コードモードより以前にあった 別のプロリクエストが新しい、
もしくは今は無効なモジュールを コードベースに導入したよっていうところですね。
3つ目として、そのプロジェクトはマージされます。
4つ目に、このマージによって メインブランチにリグレッションが
発生してしまいます。
で、最後ですね。
5個目として、問題を修正するために コードモードを再度実行しますと。
ああ、はいはい、そういう意味で再度実行。 複数回実行するって言ってるんですね。
ああ、なるほどですね。
プロリクエストとかマージのタイミングによって、
ちょっと古いものが潜り込んじゃう可能性があって、
そのプロジェクトがマージされてしまったところで、
コードモードをもう1回やらなきゃいけないよってことですね。
そういうケースは確かにありますね。
リグレッションのスピードであったり、 リリースのタイミングが前後するみたいな話なので。
もしコードモードがべき状でなければ、
べき状って言ってるけど、 これべき等じゃないのかな?
べき状なのかな?
えーっと、ハイレンポテントっていう読み方が あるのかよくわからない。
まさかの標準の英和辞典に
見つかりませんでしたと言われたので、 諦めよう。
はい、では全部戻りましょう。
べき状として一旦読みますね。
もしコードモードがべき状でなければ、
リグレッションが発生する可能性はもちろんありますと。
例えば、ウォラスもそうですけど、
カラーオブジェクトを公開していて、
すべての色のサフィックスを何らかの理由で ベースにすることを決めたとしましょうと。
そこでcolors.blueとcolors.redっていうのは、
それぞれcolors.bluebaseとcolors.redbaseになります。
24:02
に名前が変わりますよと。
もしコードモードがサフィックスを追加するだけなら、
複数回実行すればそれは別に、
コード、じゃあcolors.bluebaseになるかもしれません。
はい。
もちろんこれでコンパイルできないですけど、
戻って修正するのは結構面倒ですよねと。
はい。
これはダリですね、確かに。
で、これをコードモードっていうのは、
even potentであれば、このようなトラブルを回避することができますよと。
はー、なるほどでしたね。
これはコードモードの使い方とか実装にもよる気はしますけども、
まあでも少なくともそういう風になる可能性があって、
それを直すのは確かに面倒ですね。
うーん、まあそもそもベータにするっていうのも結構、
これはかなりのエッジケースな気はしますけど、
まあでも可能性としてはそういうことがあり得るということですね。
でも、それを複数回実行しても、
リグレーションが発生しないようにするっていうのが本当はいいと思ってます。
そういう風に本当はしたいですよねっていう話ですね。
はい。
要は何度やっても同じような結果になってくださいっていうことが、
あのー、理想だっていう風に話になってますね。
はい。
えーと、Tooling for Automatic Upgrades Has Saved Me Weeks of Work。
ははは、なるほど。
えー、自動アップグレードのためのツールっていうのは、
私の仕事を何週間も節約してくれました。
まあ、これ辺はそうだろうな。
はい。
えーと、私はそのWallaceをバンプして、
すべての新しいコードモードっていうのを実行して、
すべてのアプリケーションでプロリクエストをオープンするツールを書きました。
ほう。
で、テストが成功すればアップグレードっていうのはすぐにマージされます。
はい。
で、製品エンジニアっていうのは、
まあ、プロダクトのエンジニアですね。
っていうのはバンプが発生したことを知る必要さえないこともあります。
ははは、いいね。
で、この作業によって、
私や他の人たちは何百時間もの退屈な時間を節約することができましたし、
まさに私たちが自動化したい種類の作業です。
はい。
まあ、これはそのまんまですね。
えー、続いてあと4分。
あと4分で、
あと4分だけでいけそう。
がんばるぞーい。
えー、次ですね。
Static Analysis Is Kind…
Kindはキングかなって言ってますね。
はい。
静的な解析が王様だって言ってます。
はい。
王様か。
はい。
えーと、いきましょう。
で、ツールを増やしたり、
まあ、開発者がコンポーネントライブラーをどのように消費しているかを知るっていうことは、
最終に取り組むべきことを決定するためにはもちろん必要にはなりますよ。
で、私たちのチームっていうのは、
組織全体の全てのフロントエンドアプリケーションを分析し、
まあ、基本的な質問に答えるためのツールを構築してきました。
はい。
で、このツールは次のように動作しますと。
まあ、これまた5つのフローですね。
はい。
全てのリアクトのフロントエンドアプリケーションをクローンしますと。
で、アプリケーションごとに全てのソースモジュールをグローブで取得します。
はい。
で、それぞれをASTにパースして、
ASTをクエリすることでデータを収集します。
あー、はいはいはい、そういうことね。
で、全てのアプリケーションのデータを一つのブログにマージします。
で、ブログを解析してインサイトを得ると。
あー、ね。
グローブにしてASTに変換してデータ取ってきて、
27:01
グローブにマージしてグローブを解析しようと。
はい。
OK。
で、例えば、UglasコンポーネントのXが毎回スタイルドコンポーネントでアップされたのかっていうのと、
どのCSSプロパティが最も変更されたのかなどの質問に答えるクエリをチェックインできるようにしています。
どのCSSプロパティが最も多く変更されているかを、
あるコンポーネント、
そう、なんだこれ、日本語がもう大変だな。
どのCSSプロパティが最も変更されているかどうかっていうのを、
あるコンポーネントは他のコンポーネントと一緒にインポートされてるだけなのか、
などなど、みたいなことですね。
その問いに答えるようにしていると。
質問の仕方は自由ですけど、
ここではコンポーネントライブラリで話をしています。
はい。
で、何十万行ものコードからこれらの答えを推測しようとすることを想像しなさい。
このツールに対応されないと。
まあ、それはそう。
はいはいはいはい。
開発中にそういう疑問が結構出てくるってことですね。
はい。
でもまあ、ライブラリをそんなにがっつり使われるようなライブラリを作ったことがないんですけど、
そのCSSプロパティが最も多く変更されているのはどれなのかみたいなのって、
結構解析したりするもんなんですね。
うん。
とか、とあるコンポーネントが他のコンポーネントと一緒にインポートされるだけなのか、
まあそれは結構調べると思いますけど。
プロパティが最も多く使われているみたいなところまで、
まあ今回のこのウォーラスっていうライブラリはそういうのであるらしいですね。
うーんって感じですね。
さらにこれらのクエリっていうのをRESTのエンドポイントで利用できるようにすると、
ダッシュボードとかメトリフィックスの設定も簡単になります。
さらにジラチケットを書くためのツールもあったりすると。
ははは。
すごいな、そんなものもあるんですね。
ジラチケットを書くためのツールもある。
もうジラでそのまま書けばいいけど、もうちょっと簡単なんでしょうね。
はい。
右下がりに動く技術的塞いを特徴付けるグラフを見るってのはいいことですよって言ってますね。
はい。
そのためのやっぱりスタティックアナリシスですね。
静的解析っていうのはやはり素晴らしいよっていう風に言ってます。
このチームとしては静的解析をするときに、
さっき言った通りとりあえずGlobeにしてASTにして、
データ取ってきてBlobにマージして、
そのBlobを解析するっていうのを静的解析のフローのメインにしてるってことですね。
なるほどね。
これでもすごいですね。
しっかり、やっぱASTに変換してるっていうところが個人的にはいいなと思いましたね。
はい。
続きまして、
ビジュアルリゲーションテストですね。
ビジュアルリゲーションテストは、
バリアブル than ユニットテストって言ってますね。
はぁはぁはぁ、なるほど。
ビジュアルリゲーションテストって、
ユニットテストには価値があるよって言ってますね。
フロントに関してはそうかもしれないですね。
フロントって基本的に来たものを色付けして表示するっていうのが基本的にやることなので、
ユニットテストをフロントエンドで書くことって実はそんなにない感じがしますし、
どっちかというとビジュアルリゲーションテストの方がよっぽど大事だったりすることもありますしね。
最終的に見るのはビジュアルリゲーションだったりしますので。
例えばジェストを使ったイメージのスナップショットテストってのは非常に貴重ではあります。
コンポーネントの全てのバリエーションと状態っていうのも繰り返して、
30:01
各ステップで画像のスナップショットを取得して、
コンポーネントの最後のバージョンと比較をします。
このスイートっていうのは、
プレゼンテーションのいかなる違いも失敗のトリガーとなるように設定可能ですと。
違いがあることを期待しましたかと。
何かを修正する必要があるようですねと。
というところでした。
この方はジェストだけでイメージスナップショットを取っているということですね。
ビジュアルリゲーションテストのツールもたくさんあるし、
今はサイプレスもありますし、
レグスーツっていうのもあったりしますし、
もちろんジェストを使ったそのままでもいいです。
あと、なんだっけ、エンジンム?エンザイム?
ちょっと読み方言わないといけないですけど、ああいうやつもありますね。
スナップショットテストっていうのもあったりするので、
本当は画像とか画面のスナップショットを取ったサブを取るサイプレスだったり、
レグスーツを使うのほうがいいかもしれないですけどね。
ただ結局画面に出てくるのはソースコードなので、
ソースコードレベルでのスナップショットとしてのエンザイムを使うのもいいんじゃないかなと思ったりしています。
ラストですね。
ラスト、ビジュアルリグレッションテスト、
ペイン2セットアップ、バッドデフィニットリーワースイットって言ってますね。
ビジュアル回帰テストってセットアップが正直面倒です。
しかし間違いなくその価値は高いですよって言ってますね。
画像のスナップショットを取得するためのテストハーネスがかなり厄介ではあります。
それはあなたのマシンでスナップショットテストを実行しているOSっていうのが、
CI上のOSと同じであることを必要とします。
実行環境に影響するのは確かにその通りだと思います。
もしあなたがCI上でLinuxイメージを実行しているのであれば、
おそらくそうでしょうけども、
あなたはMacBook上のDockerコンテナでスナップショットを実行する必要があります。
まあそうですよね。
それはLinuxはMacOSと異なる方法とスムージングを使用しているため、
CI上でテストを実行すると失敗するためです。
これはまだ解決してないのでしょうか。
誰か私にメールしてくださいと。
解決策がまだ出てないので誰か教えてくれと。
さらに実行速度が非常に遅くなって予期せぬ失敗をすると
デバッグが結構面倒になりますよと言ってました。
やっぱりビジュアリティションテストまで行くと、
確かにもう実行動作環境までちゃんと同じにしたいというのは
確かにその通りなので、
基本的なDockerを使って同じ環境を用意できる、
OSを用意できるイメージとかを持ってきて、
それを実行してコンテナを作るのがいいと思いますね。
以上、ダラダラと読んできましたけれども、
最後締めとして、
the tweet for nowということで今はこれだけしかないですよ。
もし何か意見があったりしたら、
tweetでもDMでもメールでもいいので、
お気軽に投げてくださいということでした。
ちょっと時間をオーバーしましたけど、
今回の朝方はこれで以上にしたいと思います。
途中途中、分かりづらかったり、
コンテキストが難しかったりとか、
この方は独有の考え方もあったりして、
いろいろ思うところはなくはないですけど、
全体的にすごく勉強になったし、
なるほどなという参考になることがたくさんあったので、
この記事は皆さんでも読んでいただくといいと思います。
特にリアクトで開発している方というのは、
ソースコード全部リアクトになっていますし、
参考になるなと思いました。
33:00
あとは、スベルトであったりとかソリッドJSとかでも、
思想というかコンセプト的なところは、
全然使ってもいいものになってくるので、
こういう設計の考え方とかをドキュメントに書いてあるのは、
すごくいいなと思いましたので、
ご参考までに読んでいただければなというところです。
ちょっとすみません、僕があまり理解力が弱くてですね、
途中ふーんふーんっていう感じの、
ちょっとグダグダなグー付きになってしまったので、
ちょっと申し訳なかったんですけど、
ここはちょっと不勉強というところで、
お流しいただければすごくありがたいなと思います。
じゃあまた明日はですね、何を読むかまた悩ましくてですね、
なんかネタを募集していますが、
何もネタが出てこなかったら、
前回のようにJSインフォのような
ウィークリーニュースがあるんですけど、
それのフロントエンドウィークリーの、
確か東京っていう名前がついた外国の記事があったりする。
東京ってついてるのに海外の記事だってするんですけど。
みたいなものもあったり、
いろんなウィークリーニュースの記事を出している方がいらっしゃるので、
それの1個か2個ピックアップして、
ダダダって読んでいこうかなと思ったりしています。
もちろんアイデアとかあれば、
いつでも投げていただくのすごく嬉しいなと思います。
じゃあちょっと4分くらい過ぎてしまいましたけど、
こちらで今日の朝活は以上にしたいかなと思います。
ご参加いただいた皆さんありがとうございました。
今日もめちゃめちゃ暑いと思います。
皆さん体調管理だけは気をつけていただいて、
今日も一日頑張っていただければなと思います。
では終了します。お疲れ様でした。
