00:03
はい、10月21日金曜日ですね。 地獄は朝9時を回りました。
気づいたら、もう10月も20日を超えてたっていうので、 昨日、今朝来ていたんですけど、
もう10月も終わりが見えてくるんですね。 早いですね、もう今年も残り2ヶ月ちょっとなのかっていうところで、
ちょっと焦り始めました。 はい、おはようございます。 夢見のkeethこと桑原です。
では、本日の朝活を始めていきたいなと思います。
えーとですね、今日は、昨日も読んでました、Reactの
RFCですね。
ユーズってやつ。ユーズRFCを出されてて、それの大元となったRFC。
ゲームツリーのファーストクラスサポートフォープロミスっていうのが、
タイトルですね。
ゲームツリーのブランチ名なんですけど、まあそういうものを議論してて、そのままユーズっていうような
別のフックが追加されたというところでした。
昨日、それの話をずっとRFCを上から読んでいって、
モチベーションを読んで、ディテールデザインですね、詳細設計のところの話をずっと読んでいました。
順番にこういうのが出て、最初にAsyncServerComponentsというのが入っていて、
AsyncServerComponentsCannotContainHooksですね。
フックを含めることができないよというのと、
その
本題であるユーズですね。ユーズのプロミスっていうのを括弧で括ってやるっていうやり方ですね。
書き方についての詳細の話をしました。
続いて、ResumingSuspendComponentsByReplyingItsExecutionですね。
っていうところを入って、
ReadingTheResultOfAPromiseDuringAReplyですね。
この辺もまだ読んだ気がする。今どこまで読んだか覚え出してる感じですね。
続いて、ReadingTheResultOfAPromiseThatWasReadPreviouslyですね。
はいはい、っていうところも読んで、
ReadingTheResultOfAPromiseDuringUnrelatedUpdatesですね。
ここを読んでない気が僕はなんとなくしてるので、多分今日ここからですね、
入っていきたいかなと思います。ではでは行きましょうか。
はい、では行きましょう。
ReadingTheResultOfAPromiseDuringUnrelatedUpdatesですね。
はい、無関係な更新中にプロミスの結果を読み込みますというところからでいきましょう。
今日は多分これ、
時間内に終わってしまうので、続いての記事、先に言っておくと、続いてはですね、
もう1個読みたいのは、これを読もうと思ってた、
もともとの記事、うひょさんの記事ですね。最速攻略リアクトのUseRFCのところですね。
の続きの記事、続編の記事が載ってたので、それも読んでいこうと思います。
こっちも長いので、こっちはまた、
アシャインに続く気がしますので、そんな感じでいきたいと思います。では行きましょう。
無関係な更新中にプロミスの結果を読み込むです。
プロミスオブジェクトの結果を追跡することは、レンダリング間でプロミスオブジェクトが変更されなかった場合にのみ機能します。
で、これはJavaScriptの起動機関数がどのように動作するかも同じです。
起動機関数を呼び出すために、たとえ
データがキャッシュされていたとしても、そして全く何も
待たされていなかったとしても、全く新しいプロミスが結果として返されます。
03:01
このようなことが起こる最も重要なケースは、無関係な更新に反応して、コンポーネントが再連絡するときですね。
次の例をちょっと見てくださいということで、まだソースコードが出てます。
はい、Asyncのついた関数コンポーネントができされていて、
引き継ぎにIDが出されています。そのIDをキーにFetchDataFromCacheみたいなので、キャッシュからデータを取ってきます。
コンストデータで受け取って、
リターンをオブジェクトにしてますね。オブジェクトでキーコンテンツの中に
さっき受け取ったデータ、データ.コンテンツというので、厳密にはまだ
指定して渡して返してあげてますよと。で、もう一個ですね、functionToDoというのが
また一つ関数コンポーネントが定義されています。
引き継ぎにはIDとIsSelectedという変数を受け取っていて、
で、一発目にやることがUseですね。Use関数の中でFetchToDoというのを
実行します。受け取ったIDをベースにFetchToDoですね。さっき定義したAsync関数のことを定義して
実行して、で、その後ToDoを受け取ると。
で、受け取ったToDoをJSXの中で埋め込んでますよということですね。
こんな例を見てみましょうと。で、このようなコンポーネントだった場合ですね、IDが更新された場合、
新しいデータの読み込みが終わるまでFetchToDoというメソッドは
中断しなければならないかもしれないというのは理にかなっていますと。
しかし、IDはそのままでIsSelectedが更新された場合はどうでしょうかと。
非同期関数、IsSelectedの方はもう一個ですね、さっきのFetchToDoじゃない関数コンポーネントToDoの方ですね。
で、IsSelectedが更新された場合はどうでしょうか。非同期関数というのは常に新しいプロミスインスタンスを返すので
使用するために
渡されたプロミスというのは異なるものになります。そうね。
しかしデータはキャッシュから読み込まれたので再びサスペンドする必要はないはずです。ああ確かにそうですね。
べき当選的な話ですね。
もしリアクトがこのケースを適切に扱わないのであれば
任意の更新によって新しいデータが要求されていなくてもUIがサスペンドされる可能性があります。
そこでこれを処理するための何らかな戦略が必要ですよねと。
で、ここで私たちのトリックはより複雑になりますよと。
この場合フェッチドゥルルから返されるプロミスが
マイクロタスクで解決されることを利用します。リアクトはサスペンドするのではなくマイクロタスクのキューが
フラッシュされるのを待ちます。
その期間内にプロミスが解決されればリアクトはコンポーネントを直ちに再生して
レンダリングを再開しサスペンションフォールバックをトリガーすることなくレンダリングを再開することができます。
そうでない場合はリアクトは新しいデータが要求されたとみなさらけがならず通常のようにサスペンドされます。
これによってデータ要求がキャッシュされている限り
サスペンドを回避することができます。
プロミスオブジェクト自体がキャッシュされていれば
マイクロタスクを待たずにコンポーネントを再生することなく結果を同期的に読み取ることができるので
パフォーマンス的にはまだマシであるということは留意してください。
そのためユーザー入力イベントへの対応など優先度の高い更新時にこのような現象が発生すると
リアクトはパフォーマンスの警告を記録します。
06:00
警告を修正する方法は起動期間数をメモ化する、ユーズメモを使用する、もしくはキャッシュ化する、キャッシュを利用するですね。
これは今後のRFCで説明する予定ですよと言っています。
将来的には
自動メモ化コンパイラーがプロミスオブジェクトを自動的にメモすることでこの問題に対処できるようになるかもしれませんと言っています。
今までのRFCの前提条件をずっと頭に入れた上で読まなきゃいけないので
だんだんちょっと僕はわからなくなってきました。
なんかメモしながら読みたくなってきたんですけど、まあいいや、今日の朝勝は音読なので
わかる範囲で行きたいと思いますが
まあとりあえずそのサスペンスの条件的なお話を今しているところだと思いますね。
で、まあその自動メモ化コンパイラーというところをオブジェクトを自動的にメモすることで対処できるかもしれません
というこのメモとキャッシュ回りのところが後々に語られるということだそうですね。
では続いていきましょう。続いて
キャビートですね。注意点、データリクエストというのはリプレイ間でキャッシュされる必要がありますよねってことです。
マイクロタスがフラッシュするのを待ってからサスペンドするというメカニズムは
データリクエストがキャッシュされている場合にのみ機能します。
より正確には制約は次の通りです。新しい入力を受け取らずに再レンダリングする非同期関数というのは
マイクロタスク内で解決しなければなりません。
この注意事項は非同期サーバーコンポーネントには適用されないことに注意してください。
なぜならサーバーコンポーネントは更新を受け取らないからです。
基本的にはステートレスだからサーバーコンポーネントはそうですよ。
これはキャッシュAPIの次期RFCで広範囲にカバーされる予定です。キャッシュAPIのRFCがあるんですね。
でもリンクはなさそうなんでまたどっかで出てくるらしいですね。
キャッシュなしで出荷される可能性は非常に低いですよと。
なのでAPIは次のようなものになる予定ですと言ってます。
ざっくりとソースコードがバーっと載ってますね。
関数フェッチノートっていうのがあって、引数にキャッシュっていうのを受け取る。
キャッシュ関数っていうのを受け取っていて、それを実行する非同期関数をやっているんですね。
その結果を返しているんで、キャッシュ関数の中でawaitフェッチをしてますね。
これはフェッチはJavaScriptのフェッチAPIですね。
を使って受け取ったものをレスポンスでレスポンス.jsonをawaitしてリターンをするっていうのがフェッチノートっていう関数があって、
関数コンポーネントフェッチノートっていうところで、さっき言ったフェッチノートっていう関数を
useで挟んであげて実行すると。
そういう使い方になりますよねってことでした。
それは毎回同じプロミスを毎回毎回返してくれるはずですよねって言ってますので。
なので新しいIDが出されるとキャッシュっていうのはリフレッシュされますよねとも言ってますので、
そのIDが更新されない限りは同じものが返されるはずですよと。
はい、で既存のデータ取得ライブラリーのほとんどっていうのはこの落とし穴を避けるために十分なキャッシュ機構というのは
既に実装しているのでキャッシュを適用させる必要なしに使用パターンを採用することができるはずだということに注意してください。
これはほとんどのコンポーネント代で直接非同期関数を呼び出すことによっても生じる新しい概念です。
ああまあそうか。
まあそりゃそうだよコンポーネントで別に直接使う可能性も多いにありますからね。
09:02
うーん、なるほどな。
まあやっぱり表現力高かったり柔軟性高い分いろんなところでできたりするので規約をしっかりしなきゃいけないとかやっぱり制約を設ける方が良かったりするってことですよね。
はい、あのー、何ですか。
便利だったり柔軟性高かったり、ユーザーに自由な、自由度を与えるっていうことはカオスになるってのは正直あるので、
ある意味で不便さを与えることによってその制約の中でやってねっていうのはやっぱ本来のフレームワークでむしろそういうものだと僕は思っているので。
だからこそ人間としては同じようなコードを書くことができて、チームで開発する上でこの人がこういうコードを書いたとしてもだいたい似てくるので可読性が上がったりフォース性が上がったり、一貫性を保たれるっていうのにメリットがあるので、
どこまで柔軟性を高くするかは結構フレームワークの思想によるのでそこは難しいなと思いますね。
はい、まずは余談でした。
で、続いてデータに対して条件付きでサスペンドするっていう次の話ですね。
他の全てのフックスとは異なり、ユーズっていうのは関数のトップレベルにのみ制限されるのではなく、条件付きで呼び出すことができます。
この動機っていうのはデータを別のコンポーネントに注入することなく、データに対して条件付きでサスペンドすることをサポートするためです。
本当にサスペンドのためのフックと言っても過言ではないからですね。
で、またサンプルソースコードで来てますけど、音読が長くなるのですいませんが端折ります。
また後ほど、ソースコード自体は記事内から見ていただくといいと思います。
で、Reactコンポーネント内でユーズを呼び出すことができる場所に関するルールっていうのは、
awaitが非同期関数内で呼び出される場所、またはyieldがジェネレーター関数内で呼び出される場所に対応しています。
yieldがジェネレーター関数内で呼び出される場所に対応しています。
はーはーはーはー、なるほどね。
あとはawaitが非同期関数内で呼び出される場所っていうところでユーズを呼び出すことができる場所だっていうふうにしてるんですね。
あんまジェネレーター関数を普段使わない気はしてますけどね、僕ら的にも。
ライブラリー開発者とかだと結構出てくると思いますけど、
普段のアプリケーション開発でジェネレーター関数ってそんな使うのかなっていう印象があります。
僕が使ってないだけで皆さん使ってるんだったら、それは逆に実践の話をちょっと聞いてみたいですね。
yieldっていうワードを滅多に見なくなりましたのでね。
はい、ご視聴ありがとうございました。
続いて、ユーズはブロック、スイッチ分、ループなどの任意の制御フロー構造内から呼び出すことができます。
唯一の要件っていうのは親関数がリアクトコンポーネントまたはフックでなければならないってことですね。
例えば、ユーズっていうのはフォールブ内の内部で呼び出すことができますが、
マップメソッド呼び出しに渡されたクローチャーの内部で呼び出すことはできないよって言ってます。
単純にフォーブの中でユーズを使うことはもちろんできますが、
例えば、配列.mapでその中の関数、コールバック関数か、
コールバック関数の中でやっているユーズっていうのは使用できませんっていうふうに。
で、ユーズが条件付きで呼び出されることを許可されている理由っていうのは、
他のほとんどのフックとは異なり、更新に渡って状態を追跡する必要がないためですと。
あー、確かにそうですね。ユーズってのは状態を追跡しないものですね。
ユーズステートのようなフックっていうのはリアクトが以前の状態と関連づけられるように、
12:02
全てのレンダリング中に同じ位置で実行される必要がありますが、
ユーズはコンポーネントの単一のレンダリングを超えて生きるデータを保存する必要っていうのが特にないですと。
その代わり、プロミスのデータはプロミスオブジェクト自体に関連づけられます。
はー、そうね。
だから逆に言うとプロミスオブジェクトがちゃんと適当性を保たれたりとか、
そこのデータのやり取りがしっかりできているところであれば、
ユーズは逆に言うと使えるってことですね。
で、続いてサーバーコンポーネントからクライアントコンポーネントへのプロミスの置きを足しっていうところのセクションですね。
いきます。
サーバーコンポーネント内で計画されている機能っていうのは、
クライアントコンポーネントにプロットしてプロミスを渡すことをサポートすることです。
これはこの提案の範囲からちょっと外れますけども、
コンディショナリーユーズを呼び出せることがなぜ貴重なのかを強調するので、
あれで言及する必要がありますよと。
あ、価値がありますって言ってますね。
で、DoDoExampleって書いてますけど、
DoDoExampleのソースコードがないので、
あ、DoDoでExampleをここに書くっていう風に言ってるってことですね。
なるほどでした。はい。
で、続いて、
Other Unusable Typesですね。
その他の使えるタイプっていうので見てみましょう。
はい、その他の使えるタイプってところですけど、
保管フックスとは異なり、
ユーズっていうのは条件付きで見出される特別な機能を持っているため、
開発者は最初戸惑うかもしれません。
しかしこの機能はとても便利なもので、すぐに慣れていただけると思います。
混乱を避けるために、ユーズっていうのは条件付き実行をサポートする唯一のフックになることを意図しています。
典型的なルールから除外された少数のフックについて学ぶ必要がある代わりに、
開発者は一つだけ覚えればいいということになります。
この提案は厳密な範囲ではありませんが、
ユーズっていうのは最終的にプロミス以外の方もサポートする予定ですだと?
ユーザは最終的にプロミス以外の方もサポートする予定?はぁー。
例えば、最初にサポートされる非プロミス型っていうのはコンテキストで、
ユーズコンテキスト、ユーズ括弧コンテキストですね。
っていうのは、条件付きで呼び出されることを除けば、ユーズコンテキスト括弧コンテキストと同じ振る舞いすることになりますと。
あー、はいはい、そういうことですね。
まあまあ、紛らわしい名前ですけど。
使用可能な方っていうのはその値のための容器と考えることができる。
で、ユーズを呼び出すとそれが解き放たれるよということですね。
はい、まあ最終的にはユーズコンテキストのコンテキストは、
ユーズ括弧コンテキストに何か集約される感はある気がしますけどね。
まあ以上で一応詳細設計でした。
で、続いてよくある質問のセクションに入ろうと思います。
で、多分このよくある質問のセクションが終わったらこの記事、記事というかRFCは終わりですね。
一つ目、なぜユーズを、ユーズはもっと具体的な呼び方をしないのでしょうか。
これ多分名前の話かな。
これには2つありますと。
例えば、ユーズ括弧コンテキストもそうです。
ユーズっていうのは条件付きで呼び出すことが許されているため非常に特殊なフックです。
このアイディアはこれを唯一の条件付きフックにすることで混乱を緩和せることですよと言っています。
たくさんの条件付きフックを覚える代わりに開発者たった一つ覚えればいいっていう、
あー、そこにためにっていうことですね。
そういう意味では確かに覚えるのは確かにユーズっていうフック一つだけなので、
それのルールっていうのをそれぞれ使い方を覚えていけばいいってことですよね。
これは確かに一ついい話だなと思いました。
それぞれいろんなリンクが貼られていますけど、このRFCにないのはリンクなのでそこは割愛しますね。
続いて2つ目の質問です。
15:01
なぜユーズは通常の非REACT関数で呼び出せないのでしょうかというところを言っています。
ユーズは条件付きで呼び出せるとはいえ、
REACTがレンダリングしているときしか動作しないのでフックであることに変わりはありません。
つまりREACTのコンポーネントかフックでしか実行できないっていうところは変わらない。
理論的にはREACTコンポーネントはフックの内部からしか呼び出されない関数内で、
ユーズを呼び出せばやっぱり実行時に動くことになりますけど、
これはコンパイルエラーとして使われることになりますよね。
もし通常の関数内でユーズを呼び出すことを許可した場合、
正しい文脈で呼び出されるかどうか開発者次第になっています。
これがREACTの関数と非REACTの関数を区別するために、
ユーズという命名規則を作った理由の一つです。
またメモを取るコンパイラーが計算を再利用することも難しくなります。
任意の関数が一時停止する可能性があるというのは想定しなければならないからです。
まあ確かにね。
カバーしなければ範囲が増えてしまうので、なるべくREACTないだけでとどめたい。
確かにそうかもしれないですね。
フックとは別の命名規則を導入することも一応できますけど、
その場合だけのために別のタイプのREACT関数を追加する価値はないように思えます。
実際にはフックスを条件付きで呼び出せないことが大きな問題ではないのと同じように、
大きな問題にならないだろうというふうに考えているからですと言ってます。
これは僕も同意かもしれないですね。
外の関数で呼び出せないようにしてほしいなと思います。
そもそもユーズというのはREACTの機能なので、
それを外で呼び出せることにあんま僕も価値はないなという感じがしました。
続いて、代わりに代替名と呼ぶのはどうでしょうか。
オルタネイムというふうに呼ぶのはどうでしょうかという質問が来たらしいですね。
よくある質問でそんなのあったんや。
代替名称の提案というのは一応歓迎はしています。
しかし留意すべき点がいくつかあります。
名前はUNWRAPPEDを示唆するだけでなく、それがREACT専用の関数であることを示すべきです。
ユーズの利点というのは他のフックスが既に隔離している命名規則に基づいていることです。
別の名前にすると開発者一つではなくて二つの特別な言葉を覚えなければならなくなります。
確かにね、もうユーズなんちゃらっていうのはREACTフックスだっていうのは
もう開発者にほぼほぼインストールされたと言っても過言ではないので
ユーズっていう名前を使う限り、多分REACTの新しいフックなんだなって僕らはすでに発想ができているので
これができたっていうのは確かに大きいかもしれないですね。
初心者にこれを教えるには次の方法があります。
ユーズで始まる関数はすべてフックであり、
REACTの関数、過去コンポーネントまたはカスタムフックからしか呼び出すことができませんというのが一つ。
フックはユーズという関数、余計な文字はないというものですね。
ユーズという関数以外、他のすべてのフックはトップレベルでのみ呼び出すことができるっていうことも示唆できるということですね。
これも結構大きいですね。
逆にちゃんとREACTフックス、他のフックスっていうのはトップレベルでのみしか呼び出せないよっていうのも学習できるので
二つの理由でメリット大きいですね。
でも一応そういうオルタネイティブな名前の提案っていうのは全然歓迎していませんってことでした。
ただ今の確かにユーズっていう名前の背景だったり思想っていうのはもう崩せない気がちょっとしてますけどね。
18:03
続いてクライアントコンポーネントはなぜ非同期関数にできないんでしょうかというところですね。
私たちは非同期サーバーコンポーネントだけでなく非同期クライアントコンポーネントをサポートすることを強く検討しました。
技術的には可能だと言っています。
十分な落とし穴と注意点があるため現在のところこのパターンを一般的に推奨することには結構抵抗があります。
計画ではランタイムに非同期クライアントコンポーネントのサポートを実装する予定ですけど開発時には警告を記録することになります。
またドキュメントでもその使用を推奨しないことにしています。
できるようには設計してるけど基本的には推奨しないし警告も出すよって言ってますね。
非同期クライアントコンポーネントを推奨しない主な理由っていうのは一つのプロップがコンポーネントを通過して流れ
そのメモカーを無効にして前のセクションで説明したマイクロタスクダンスをトリガーすることがあまりにも簡単だからです。
新しいパフォーマンス上の注意点を導入するというよりも
上記のパフォーマンス上の注意点がすべて発生する可能性が高いということになるのです。
非同期クライアントコンポーネントが理にかなっていると考えられるパターンが一つだけあります。
それはナビゲーション中にのみ更新されることが保証されるという構図を持つ場合です。
しかし実際にこれを保証する唯一の現実的な方法というのは
アプリケーションのルーターに直接サポートを統合することです。
そのためこのパターンがどの程度まで文章化されるかは不明です。
少なくとも今のところは無理です。
将来的には非同期クライアントコンポーネントを特殊なジェネレーターのようなランタイムにコンパイルすることで
一般的なサポートを解除することができるかもしれません。
特殊なジェネレーターのようなランタイムにコンパイルすることで一般的なサポートを解除することができる。
そうするとイールドの話はもうちょっと復活する可能性はありますね。
イールドを使えばちゃんとループだったり処理の流れを制御できますからね、コントローラブルに。
プロミスの話とそこで絡めると複雑で面倒くさくなる気はしますけどね。
なので素直にユーズの世界に乗っかる方がなんとなくいい気もしなくはないか。
そういう意味で非同期クライアントコンポーネントは悩ましいところですね。
クライアントコンポーネントの中で非同期な処理をするんだったらまあいいですけど
コンポーネントそのまま非同期にするっていうのは確かに魅力は全然ありますし
欲しいって思う理由も僕らもあるんですけど難しいなと思うので
サーバーサイドの方のコンポーネントをまずは非同期でやるのでいいんじゃないかなという気はしてますね。
何やかんや非同期っていうのは難易な分複雑度が増すので
考慮するものが一気に増えるのでなかなか大変だなって思いますね。
じゃあ続いて、なぜジェネレーター関係ないのですかと。
この質問絶対出るんだね。
ジェネレーターの主な欠点というのは
すべてのフックがジェネレーターであることを事実上要求しなければ
カスタムフックの内部でそれらを使用することはできないよということです。
すべてのフックがジェネレーターであることを事実上要求しなければ
カスタムフックの中でそれを使用することはできない。
これはデータをロードしていない場合のランタイムに多くの余分なオーバーヘッドを追加し
同様に開発者のための多くの公文的オーバーヘッドを追加します。
この問題に対処するための一つの計画というのは
21:00
自動記憶コンパイラーが前回の生成試行時の計算を再利用することです。
もう一つの計画は非動機または待機公文というのを
低レベルのジェネレーターのような形にコンパイルすることです。
この場合フックの抽象化の問題ではなく
性能の問題を解決することができます。
抽象化の問題を解決するために長期的なアイディアとしては
フックを呼び出すためのカスタム公文を導入し
すべてのリアクト関数をジェネレーターのようなランタイムにコンパイルすることですよと。
しっかり考慮した上でこの設計になっているんですね。
僕は空のデモでも出ない感じがすごくしますけど
このRCのプルリクエストのコメントを見るとめちゃめちゃスレッドが長いんですけどね。
皆さんそれでもちゃんと意見がいっぱい出るってなかなか面白いなと思いましたね。
最後、未解決な質問で時計を上げてます。
この提案にかけている主なものは非動機リクエストをキャッシュするためのAPIである
つまりキャッシュですと言っています。
さっきも出てきましたね。キャッシュAPIのRFCがまだ完成していないので
という話をしたのでこれが唯一の残りですかね。
これは近々付随するRFCで扱われる予定です。
その時点で適切な場所に端子を含めるためにこの提案を更新する予定です。
キャッシュはこの提案が実行可能であるために必要ではありませんけど
それらを互いに念頭に置いて設計されたので
それは本当にユニットとして一緒に考慮されるべきですよと言っていますので
キャッシュAPIのRFCをお待ちくださいということでした。
というわけで以上で今回のユーズRFCの詳細を一度読んでみましたけどいかがでしたでしょうか。
正直に言うとめっちゃ難しかったです。
ちゃんと書いてないと理解できないし
逆に言うとリアクト17で導入されたサスペンドというのが
どれだけ有用性高くリアクトの大きな進化の一つだったかというのが
はっきり分かるなというのも改めて感じましたね。
またそこに新たなフックを導入する。しかもユーズという名前が
最初見た時になんかすごい雑というか汎用すぎるやろうと思ったけど
いろんな背景とか理由を知れば知るほど
この名前って優れてるなって改めて感じましたね。
まあやっぱり細かいところとか説明は僕よりも先日読んだ
ウヒョさんの記事の方が圧倒的に言語がしっかりされてるし
考慮する思想レベルのところまで書かれてるので
そちらの方を読んでいただければと思います。
僕よりも明らかに理解が深いので。
なんですけど僕も同じようにこれザーッと読んだ感じ
やっぱりこのユーズフックって実装されてほしいなと
本当に思いました。心から実装してほしいなと思っているので
そのCache APIのRFCも後ほどガッと探してみて
もし見つかったら朝勝で読んでいこうかなと思っております。
というわけで時間が30分を超えたので
本当はもう一つ読みたかった。
ウヒョさんの先ほど言った最速攻略リアクトのユーズRFC
という記事の続編である
なんでコンポーネントに副作用があんだよ
教えはどうなってんだよ教えは
っていうような面白いタイトルの記事があるので
これも読みたかったんですけど
時間がなかったのでまた明日以降読んでいこうかなと思っています。
ちょっと最近リアクトの話ばっかりで大変申し訳ないですけど
もうちょっと技術的なリアクトの話を読みつつ
また次回抽象的だったり組織論だったりの話を読むかもしれないですね。
24:01
しかも久しぶりにサーバーサイトインフラ周りの
更新記事読んでみたいかなっていう感じもしますね。
僕も一応もともとサーバーサイトエンジニアで
リアクトとかRubyとかNanoJSでAPI作ってたので
その記事も読みつつサーバー側の方の知識も増やしていきたいかなと思っていますので
お楽しみいただければと思います。
逆にこんな記事読んでとか
こんなものなんか面白そうな記事ないのっていうアイディアだったり
トピックあったらどっち投げてください。
それをベースにいくかあと探しますので。
ついでに僕がフロント周りの人間なので
結局タイムラインとか情報流れてくるものが
だいたいフロントの知識が多すぎるので
この辺は課題だなと思うんですって感じですね。
では今日の朝活はこちらで以上にしたいと思います。
今日も朝から大変多くの方に参加していただきありがとうございました。
一緒に学べるっていうところが本当にありがたいですし
来てくださることで僕も勉強せねばっていう強い気持ちになるので
本当に感謝しています。
では金曜日ですね。
最後1週間終わりですけどしっかり締めて
ゆるーく金曜日休日に過ごしていただければなと思います。
では終了したいと思います。
お疲れ様でした。
