00:05
はい、みなさんおはようございます。株式会社ゆめみでポストチャレンジ総理締め工事をしておりますキースこと桑原です。
Web 業界なんでも雑談室でようこそ。この番組ではWeb 業界に関することをまた様々な学びになるコンテンツを目指してお届けしていきたいと思います。
本日からですね、朝活を配信していこうかなと思います。
こっちのライブ配信ではなくて、今もやってますツイッタースペースで技術的なものだったり、自分がネットで見つけた記事とかを
ただ読んでるだけなんですけど、その配信ですね、やっぱり流れてしまうというか、一度録音もできるんですけど、
やっぱり一定期間に撮ってしまいますし、せっかく配信データとしてもったいないので、音声でも収録をしてこちらにも流していこうかなと思って、
今日からやってみたいなと思っております。では本編をどうぞ。 おはようございます。
今日も朝活をやっていきたいかなと思います。 昨日に引き続きですね、リアクト18のブログを読んでいこうかなと思います。
リアクトのバージョン18も話題になったんですけど、僕が全然覚えてなかったので、公式ブログを読んでいこうというところですね。
昨日は読み始めてて、
新要素、新機能のところまで話が入りました。 自動バッチングとトランジッションですね、
そのところまで入ったところが終わったのかなと思いますね。 なので今日は続いてサスペンスですね。
みんなの好き、サスペンスの機能のところのお話まで入っていこうかなと思います。 朝からちょっと我が家はうるさいんで、
雑音が入ったら大変申し訳ないですけど、一応読んでいきたいと思いますね。 サスペンスの新機能ですけども、
サスペンスによりコンポーネント取りの一部がまだ表示できないという場合に、 ロード中というような状態を宣言的に記述できるようになりましたよって言ってますね。
皆さんも一度コードを見たことあるかもしれないですけど、 サスペンスっていうコンポーネントですね、本当に。
タグがあって、その属性とかアトリビューズの中にフォールバックっていうのを指定できると。 フォールバックイコール、ローディング用のコンポーネントとか、
文言とか適当なものを載せられますねと。 公式サイトのソースコードでは、スピナーっていうコンポーネントがあって、それを指定してますね。
挟んであげて、中身のコンテンツのタグを入れてあげると。そんな感じですね。
サスペンスによってですね、UIがロード中という状態を、 Reactのプログラミングモデルで宣言的に記述可能な使用コンセプトにも昇格ができますよというふうに言ってますと。
その上に、より高レベルな機能を構築していけるようになりますと。 とにかくサスペンスを使えば、もう一つレベル高いことができると言ってますね。
我々というのは、数年前に機能を限定したサスペンスの実装を導入したことがありますと。
03:00
しかし、サポートされているユースケースというのは React.lazy みたいな、要はコード分割のみしかなかったんですね。
サーバーのレンダーとかについては一切サポートしなかったというふうに言ってました。
React 18 では、サーバー側のサスペンスのサポートを追加しまして、 並行レンダリング機能を用いてその能力を向上させたよというふうに言ってます。
僕は全然追ってないし、 React.lazy でコード分割しただけだったんだというのすら、今初めて知ったんですけど。
React 18 におけるサスペンスというのは、トランジッション API と併用した場合に能力を発揮すると。
トランジッション中でサスペンドが発生すると、 React はすでに見えているコンテンツがフォールバックによって隠されてしまわないようにするのです。
その辺を勝手にやってくれるのは素晴らしいですね。
代わりに十分なデータがロードされるまで、 レンダー遅らせて望ましくないロード中状態が見えないようにします。
なるほど、そんな感じなんですね。 詳しくは、サスペンス in React 18 っていう RFC があるので、その辺も見て頂ければなっていうことを言ってました。
はい、あ、だいちさんおはようございます。 ご参加いただきありがとうございます。昨日に引き続き React 18 のブログをただただ読んでます。
新たなクライアントおよびサーバー用のレンダー API っていうのが先ほどの話にも出ましたので、その辺の次のセクションに入っていきたいと思います。
今回のリリースを機に、クライアントおよびサーバー用に公開している API っていうのを再設計することにしたそうですね。
これによって React 18 っていうのは、新しい API にアップグレードするまでの間、 React 17 の古い API を利用し続けることができるようになります。
いわゆる介護完成がありますよってことを言ってますね。
で、その中の一つに React DOM クライアントっていうのがあるそうですね。
はい、ほっぺさんもご参加いただきありがとうございます。 タイトルにある通り React 18 のブログをただ読んでます。
はい、まあ以下のような新たな API が React DOM スラッシュクライアントっていうところからエクスポードされるようになっていますよと言ってました。
一つがクリエイトルートってやつですね。クリエイトルートで、これ何かというとレンダーしたりアンマウントしたりできる新たなルートを作成するための新メソッドっていうのが実装されたらしいですね。
はい、React DOM .render の代わりに利用してくださいと。
.render の代わりにクリエイトルートメソッドを使ってくれと。 これを使わないと React 18 の新機能は動作しないっていうふうにも断言しているので皆さんこっちを使いましょうということでした。
結構これちょっと破壊的じゃないと思ったんですけど。 あ、でもあれか。使ってない人は単純に今までの React DOM のレンダーメソッドを使えばいいって話か。
なるほどね。 18 使いたかったらクリエイトルートに乗せ替えてくれよっていう。
なので単純にバーチャルアップしただけだと動かないんじゃないか? あーそうか。動かないんじゃなくて、動くんだけど 18 の機能が使えませんって言ってるだけなのでアプリとしては動くので一応介護可能性は保っているってことですね。
なるほど。 続いて、ハイドレイトルートっていうメソッドが実装されたらしいですね。
サバットさんですね。ご参加いただきありがとうございます。 ハイドレイトルートっていうメソッドはサーバーでレンダーされたアプリをハイドレーションするための新メソッドです。
06:05
名前の通りでしたね。 これも react-dom.hydrate っていうメソッドがありましたけど、それの代わりに新たな React DOM サーバー API と合わせて利用してくださいよっていうふうに言ってますね。
これを使わないと 18 の新機能は動作しません。 言わなきゃいけないんだろうなこれは。
というわけで React 18 を使いたい場合はクリエイトルートとハイドレイトルートっていうメソッドをちゃんと併用して使ってくださいねということだそうです。
いかないと動かないらしいです。 今述べた2つのメソッドはいずれもオンリカバラブルエラーという新たなオプションを受け取るようになっていて、
レンダーもしくはハイドレーション中に起きたエラーから React が復帰した場合に通知を受けてログを残したい場合に利用できます。
これ大事ですね。この辺やっぱちゃんとケアをしているっていうのが React の素晴らしいところではありますよね。
オンリカバラブルエラーというオプションが取れるようになったらしいですね。
デフォルトでは React っていうのはレポートエラーか、クリエイトルートの場合はコンソールドットエラーを利用しますと。
React ともクライアントのドキュメントがあるので、こちらを見てくださいねということも言ってますね。
一応ざっくり開いてみるが、そんなに長くないけど、ちょっとソースコード的な説明になってますね。
ブラウザーサポートのところが、古いバージョンを使えばやっぱりポリフィールが必要かもしれないねってことも一応注記したので、
モダンブラウザーであれば基本動きそうな感じはしますね。 続いて React DOM サーバーですね。
こちらもいくつかの API が実装されてますよということを言ってますね。
こちらもさっきの React DOM スラッシュクライアントからエクスポートされるようになっていて、
サーバーでサスペンスをストリーミングする機能を完全にサポートしています。
2つのメソッドのうち1つが RenderToPipeAbleStream か。
これは何かというとノード環境でのストリーミング用のメソッドだと。
もう1個が RenderToReadableStream でしたね。
こちらは Dino とかクラウドフェアワーカーズのようなモダンなエッジランタイムの環境用だそうですね。
すごいな。
エッジランタイム用にちゃんとメソッド用意してその辺もストリーミングをサポートしてるんですね。
すごいな。
たぶん基本ローカルのアプリで使う場合は PipeAbleStream の方を使うんでしょうけど。
これら既存の RenderToStream メソッドは今後も動作しますけど、もう推奨しませんと公式が言ってますので、
18 位に上げたい人は、さっき言った RenderToPipeAbleStream と RenderToReadableStream の 2 つのメソッドを使ってくださいと。
いわゆるサーバーの方との連携をする人たちはということですね。
続いてストリートモードの新たな挙動というところですね。
09:05
将来的に React がステートを保ったままで UI の一部分を追加削除できるような機能を導入したいというふうに考えていると。
例えばユーザーがタブを切り替えて画面を離れて戻ってきた場合に、
これ昨日もそんな例が出てましたね。
タブから戻ってきて React が以前の画面をすぐに表示できるようにしたいよねっていう需要はあると。
これを可能にするために React は同じステートを使用してツリーをアンマウントもしくはサイマウントするようにしています。
これはやっぱり仮想ドームの強みでもありますよね。
ちょっとその代わり、マシンのメモリ食いそうな気はしますけど。
この機能によって React の標準状態でのパフォーマンスは向上しますが、コンポーネントは副作用が何度も登録されたり破棄されたりすることに対して耐性を持つことが必要になります。
それは確かにそうですね。
副作用といっては、いわゆるエフェクトとかその辺もろもろみたいなところだと思います。
ほとんどの副作用というのは何の変更もなく動作はしますけど、一部の副作用は一度しか登録破棄されないものと想定してます。
この問題に気づきやすくするために React 18 っていうのはストリートモードに新しい開発時専用のチェックを導入しています。
この新しいチェックは、コンポーネントが初めてマウントされる度に全てのコンポーネントを自動的にアンマウントもしくはサイマウントし、かつ2回目のマウントで以前のステートを復元します。
マウントされる度に全てのコンポーネントを自動でリマウントしているってことですね。
かつ2回目のマウントで以前のステートを復元している。だから一度マウントしてしっかり中でステートを持っているってことですよね。
中のソースコード見てないけど多分メモカーうまいことホニョホニョ使って保存してるんだろうと予想しています。
React は勝手にやってきてくれるってことですよね。
これまでは React っていうのはコンポーネントをマウントして以下のように副作用を作成してきました。
React がとりあえずコンポーネントをマウントしたらレイアウトエフェクトというものを作成します。
その後通常の副作用を作成します。というのが今までの React のマウントした時の流れだったそうですが、
React 18 のストリクトモードでは開発時にコンポーネントがマウントされた場合、React コンポーネントの即時アンマウントとサイマウントをシミュレーションします。
シミュレーションをしている厳密には。
フローとしては、まず一回 React がコンポーネントをマウントします。で、レイアウト副作用を作成します。で、副作用を作成します。
通常の方の副作用を作成します。そこまでは一緒なんですけど、その後に二工程挟んでますね。
大きく二工程で、一つ目はマウントされたコンポーネント内で副作用の破棄をシミュレートします。
12:05
で、レイアウト副作用というのを破棄して、通常の副作用も破棄します。で、続いてマウントされたコンポーネント内で以前のステートを復元し、副作用の再生成をシミュレートします。
で、同じようにレイアウトと通常の副作用の作成をして、
で、こっちの方は最後に作成したコードの実行もしちゃうらしいですね。で、元通り復元をするということをやっている。
だからシミュレートをするけど結果的には実行しちゃってるっぽいな。でもシミュレートって書いてるんであれば、コミットしてないんじゃないかな、気がするな。
いわゆるなんかフォールバック的なものがなんかできるのかな、わかんないですけど。 そういうチェックを入れて、で、ステートの状態を復元するようになっているということですね。
これをストリクトモードにぶち込んでいるそうですね。 ストリクトモードなのかどうかっていうのを置いといて、でもこれはありがたいですね。
今までは多分状態っていうのを極論どっかのステートとかデータキャッシュとかに置いといて、で、画面戻って状態を検知して、で、そこから
僕らがそういうコードを書いたことは昔の僕もありますし、今もそうなってる気がしますけど、リアクト18のストリクトモードではそれを
自動でやってくれるのかな。少なくともコアの機能に入っているっていうので、これはありがたいですね。
なるほど。で、ステートの再利用可能性の保証についてまたドキュメントが別途分かれていて、そっちのブログもありますのでそれも読んでください。
これはブログじゃなくてちゃんと公式ドキュメントにありますね。
はい、あるのでそこも読んでくださいねということでしたが、時間的にどうだろうな、余裕があるならちょっと読みたいかとは思ったんですけど、
長いかな。あ、いけそうだな。いけそうなのでちょっと軽く読んでみますか。これ僕が気になってしまったので読んでみたいと思いますが。
ステート再利用可能性の保証というところですね。将来的にリアクトがステートを保ったUIの一部分とか追加削除できるような機能を導入したいと考えているけど、
その辺の話はさっきと同様ですね。でもこれを可能にするときにリアクトはアンマウントする前にコンポーネントが使用している前のステートを使用してツリーを再マウントする機能をサポートしていて、
ここまでが一緒ですね。これによってリアクトの標準状態でのパフォーマンスは向上するけど、副作用が何度も、この辺も被ってますね。
これをしないと基本的に副作用は何も変更もなく動作はしますけど、一部の副作用というのはその廃棄するだけですね。
アンマウントするときのコールバックでいわゆる効読を適切にクリアアップしなかったりとか、暗黙のうちに一度だけマウントまたは廃棄されるものと想定したりすると。
そんなことが起きそうですよね。これらをサポートするためにさっきと同じようなことを1回チェックを入れてますよということですね。
自動的に全コンポーネントのアンマウントとサイマウントを走らせています。この辺も一緒ですね。
15:03
2度目のマウントにおいてリアクトは初回マウントとの時のステートを復元します。この機能はタブを操作して戻ってくるみたいな
ユーザーの挙動をシミュレートしたものであり、そういう挙動自体をシミュレートしたものなんですね。
コードがステートの復元を正しく処理できることを保証できます。
コンポーネントがアンマウントされる場合は副作用は通常通り破棄されます。
レイアウトの副作用と通常の副作用ですね。 アンマウントサイマウントで以下が発生します。
これは昔ながらのコンポーネントディズマウントとコンポーネントウィルアンマウントとユーズエフェクト、ユーズレイアウトエフェクト、そしてユーズインサーションか
エフェクト。この5つが発生しますと発火するということを言ってますね。
なるほどね。これら1年ガーッと流してアンマウントサイマウントしているというような感じですね。
補足としてこの挙動というのはいわゆる開発モードの場合にのみ適用されます。 本番用の挙動は変わりませんよと言ってました。
なるほどね。開発用なんだ。 ってことは本番用にはちゃんと別途対応しなきゃいけないっぽい気がする。
なるほどですね。 ちょっとこれは考えながら使おう。すぐに導入したいというのではなくてちょっと検証したいですね。
本来のドキュメントに戻りますね。 先ほどまでがストリクトモードの話で続いて新たなフックの話ですね。
新たなフックとしてユーザーIDというのがあるらしいです。 ユーザーIDですね。ユーザーIDっていうのはアイドレーション時の不正義を防ぎつつ
クライアントサーバーで一時のIDを生成するためのフックです。 これは主に一時のIDを必要とするアクセシビリティAPIを組み込むようなコンポーネントライブラリーで有用なものです。
これによってリアクト17及びそれ以前からすでに存在した問題は解決されますが、リアクト18では新しいストリーミング対応のサーバーレンダラーがHTMLを順番通りに送信しなくなるので、この問題はより重要ですよね。
これ詳しくはこちらのドキュメントを見てください。 というものがあります。
なるほどですね。 ちゃんとクライアントサーバーで一時のIDを生成するというようなフックが一個
公式から用意されたらしいですね。 今まで多分一時のIDを自分たちで生成してたんですけど、それがリアクトのそもそもののやつで持っているっていう感じですね。
補足として、ユーザーIDというのはリスト内のキーを作成するために使うものではありませんと書いてますね。 キーは新たなデータから作成されるべきですよって言ってました。
なるほどですね。これは大事ですね。
リストの時のキーを作成するために使うもんじゃないよっていうので、 逆に言うと使ったら何か起きそうですね。
この辺は誰かやって記事変えてないかなというのを探してみようかと。
続いてのフックですね。続いてUseTransitionですね。 これは昨日出てきたワード更新です。
18:04
UseTransitionとStartTransitionにより一部の更新というのは緊急性が低いということをマークできるようになります。
その他の更新はデフォルトで緊急性が高いものとして扱われます。
リアクトの緊急性の高い更新、例えばテキスト入力の更新とかは、 緊急性の低い更新、例えば検索結果のリストのレンダーを中断できるようになります。
こちらもドキュメント見てねってことでした。 昨日も見てた通りですけど、確か緊急性低いものは緊急性高い更新が入ったら中断されて先に高い更新が走った後にまた走らされるみたいな感じだったと記憶してますね。
それを使う時もやっぱりUseTransitionとStartTransitionをうまいこと使ってねってことだったと記憶してます。
続いて、UseDifferedValueっていうフックが入ったそうですね。名前の通り感はありますが。
UseDifferedValueによって、ツリー内の緊急性の低い更新の再レンダーを遅延させることができます。
ディバウンスに似てますけど、それと比べていくつかの利点がありますよね。 遅延時間が固定じゃないので、最初のレンダーが画面に反映された時点ですぐに遅延されていた方のレンダーを始められるようになる。
最初のレンダーが画面に反映された時点ですぐに遅延されていた方のレンダーを始められる。
また、遅延されたレンダーは中断可能であって、ユーザーインプットをブロックしません。
よりユーザーに操作を早く返してあげるっていうことができるようになりますよねってこと言ってますね。
ユーザーをブロックしないっていうのは結構大事なことだと思うんで、この辺は結構使われるんじゃないかなと思いますね。
UseDifferedValueっていうものですね。
続いて、UseSyncExternalStore。
名前すごいな。
UseSyncExternalStore。
外部ストアですね。
外部ストアへの更新を強制的に同期的に行うことで、外部ストアが並行読み取りを行えるようにします。
そういうことね。
名前通りですね。
エクスターナルストアと本当にシンクをするってことですね。
しかもこれを強制することができるのか。
これによって外部のデータソースに行読する際に、UseEffectを使う必要がなくなるので、リアクト外部の状態を扱うあらゆるライブラリにとって推奨されるものです。
これいいですね。
なるほどね。
今までたぶん確かにUseEffectでガチャガチャやってたけど、これ使わなくてもよくなるんだ。
今いいって言ったけど、どういうケースだ?
そうか、UseEffectで第2引数で配列的にこれとこれみたいな指定してたけど、こういうのは別にやらなくても、UseSyncエクスターナルストアでうまいことやったりすることができるようになると。
補足としてこれはアプリケーションコードではなくてライブラリで使用されることを意図している。
なるほどね。
リアクトと連携するエコシステムのサードパーティーのライブラリの方で使われることを意図しているってことか。
おそらく。
僕らが使うことってそんなないのかもしれないな。
21:02
結局僕らはUseEffectを使うことが多いのかな。
一応こちらについても詳しいドキュメントがありますが、読める気がするので読んでみよう。
UseSyncエクスターナルストアというのは、選択的ハイドレーションやタイムスライスなどの平行レンダリングの機能と互換性を保ちつつ、外部データソースから読み出しやデータの公読を行うために推奨されるフックです。
ちなみに引数1つ目がサブスクライブで、2つ目がスナップショット、3つ目以降はオプショナルなサーバーのスナップショットみたいなところですね。
引数1つ1つの説明をすると、1つ目のサブスクライブという引数は、ストアに変更があった場合に呼び出されるコールバックを登録するための関数だと言っています。
2つ目のゲットスナップショットというのは、現在のストアの値を返す関数です。
3つ目のオプショナルなもの、ゲットサーバースナップショットというのは、サーバーレンダリング時にスナップショットを返すための関数です。
最も基本的な例では、ストア全体を単純に購読すると。
引数1つ目にストア.サブスクライブと、2つ目にストア.ゲットスナップショットみたいなのをザッと投げてしまうという感じですね。
ただ特定のフィールドを購読するようにもできます。
これは引数は一緒で、2つ目のところをコールバック関数にして、ストア.ゲットスナップショットメソッドを実行したレスポンスに.セレクティッドフィールドみたいなふうに指定してあげれば良いと。
なるほどね。
まるっとやらないで、単純にちゃんと1個1個指定して、購読することもできますねって言ってました。
サーバーレンダリングの方では、サーバーで使われるストアの値をシリアライズしてシンクエクスタナルストアに渡す必要がある。
文字列にしろって言ってますね、つまり。
リアクトハイド連償中にこのスナップショットを利用して、サーバーとのミスマッチを防止します。
この辺は多分いろいろ実装を悩んだんだろうけど、シリアライズっていう落としどころにたどり着いたんだろうなって感じがしますね。
補足がもう1個あります。
ゲットスナップショット、2つ目の引数の方ですね。
というのは、キャッシュされた値を返す必要があります。
もしゲットスナップショットが連続して呼ばれる場合は、その間にストアの更新がないのであれば全く同一の値を返さなければなりません。
F2のリアクトのバージョンをサポートするための5階のライブラリーが、UseSyncExternalStore//SIMとして提供されています。
このライブラリーは、UseSyncExternalStoreが存在する場合はそれを優先して、利用してない場合はユーザースペースでフォールバックしてくれるようになりますよと。
ポリフィルに近いですね。
便宜のため、ゲットスナップショットの欠陥に対する自動的なメモ化をサポートしたバージョンのAPIを、UseSyncExternalStore//WithSelectorとしても公開していますよと言っています。
なるほどですね。
18を使っていればデフォルトで組み込まれているからそっちでいい気がしますが。
そんな感じでしたね。
24:01
なるほど。
使うのかな?
この辺は僕が今パッとわからないので、誰か知っている人いたら教えてくれると嬉しいかもって感じですね。
一応僕の中でも後ほど調べてみようと思います。
ラストのカスタムフック、新しいフックですけど、ラストはUseInsertionEffectですね。
これは、いわゆるCSS in JSライブラリーがレンダー時にスタイルを注入する際のパフォーマンス上の問題に対処できるようにするための新しいフックです。
既にCSS in JSライブラリーを構築しているのでなければこれを使うことはまずないけど、現代使った人がほど多いから使うでしょうね。
このフックっていうのはDOMが書き換えられた後のレイアウト副作用ですね。
レイアウトエフェクトが新しいレイアウトを読み込む前に実行されます。
いいね。
これによってReact-17及びそれ以前から存在していた問題が解決されるんですけど、
React-18では並行レンダー中にブラウザーに処理が渡って、レイアウトが再計算される可能性があるため、ここは注意してくださいねってことを言ってました。
こちらもやっぱりアプリケーションコードでなくてライブラリーで使用されることを意図してますねって話をしてます。
なるほどですね。
本当にいろんなことを考えてReact-18をリリースしたんだな。
一応こっちの別ドキュメントが切り出されていて、すごい短いのでサクッと読んじゃいますね。
UseInsertionEffect、これは引数に1個だけ受け取ってますね。
これなんだ?
SignatureっていうのはUseEffectと実は同一なんですけど、全てのDOM更新の前に同期的に読み出されます。
ここがUseEffectの違いかな。
全てのDOM更新の前に同期的に読み出されるものだっていうところですね。
UseLayoutEffectでレイアウトを読み出す前にDOMにスタイルを注入するために利用してください。
はぁ。
UseEffectでレイアウトを読み出す前にDOMにスタイルを注入するために使ってくださいねと。
このフックの利用目的は結構限定されているため、Refにアクセスしたり、更新をスケジュールしたりすることはできませんと言ってます。
結構ニッチなケースだな、そうすると。
なるほど、少なくとも僕らがそんな使うかって言うとどうなんだろうな。
あんまりパッと浮かばないけど。
よっぽど複雑なこととかテクニカルなことをしない限りは使わない気がしますね。
はい。
これは補足として、UseInsertionEffectというのはCSS in JSライブラリーの作者以外が使うべきではありません。
はい、なかったです。ちゃんと公式で言ってました。
UseEffectやUseLayoutEffectを通常扱ってくださいというふうに書いてましたので、それに従いましょう。
なので、エモーションとかスタイルコンポーネンスを作っている人たちが使うようなライブラリーっぽいですね。
フックですね。
はい、ということでした。
今ので新しいフックの実装終了で、ラスト。
ラストはアップグレード方法について書いてますけども、
ステップバイステップのガイドとか破壊的変更とか注目すべき変更前リストについてはアップグレードガイドっていうのを別で作ってますので、それを見てくださいと。
27:00
あとはもうひたすらどういう更新がありましたかっていうのをガッと羅列している感じなので、一応今回のドキュメントとしてはこちらで以上かな。
はい、でもう一個そのHow to upgrade to React 18っていうのがあって、
長いプラスひたすらソースコードだらけなので、これに関してはちょっと皆さんの方で読んでいただければっていう感じですね。
これはただ今までの読んできたものを一個一個丁寧にやり方とかを沿って説明してるって感じなので、
まぁ実際に手を貸す人はこっちを見ながらReact 18に入っていただければいいんじゃないかなっていう感じですね。
はい、なるほどね。
ちゃんとこの何ですか、テーブルオブコンテンツ見ると、アップグレード、いやアップデートか、アップデートクライアントレンダリングAPIとか、
あとはサーバーレンダリングAPIとかちゃんと一個一個項目に分けられて、そのレンダリングの方法とかアップデートの方法が本当はステップバイステップで手順がちゃんと書かれていますので、
この辺見ていただけば。で、ちゃんとUpdate to TypeScript DefinitionsっていうTSの定義についても書いてある、言及してますので、その辺も見ていただけばって感じですね。
基本的にはattypes/.reactもしくはattypes/.react-domのディペンデンシーズの最新のやつを使ってもらえればいいよっていうふうに言ってますね。
これはありがたいですね。
とか昨日も読んでた自動バッチングであったりとか、その他諸々新しいAPIとかその辺のライブラリとかについても説明が書いてありましたね。
さっき言ってたUse Insertion EffectとかUse Sync External Storeについてももう少し説明が書いてましたので、この辺も見ていくかもしれないですね。
あと、その辺もろもろバーチャーって書いてあるんで見ていただければっていう感じで、時間が近づいてまいりましたので、今日はこちらで朝活は終了にしたいかなと思います。
明日の朝活どうしようかな、明日から何を読もうかっていうのは今のところノーアイディアなので、何かしら誰かのアイディアとかこれを読んでくれみたいなのがあればそれを読んでもいいかなと思います。
なければ自分で何かしら考えて勉強していきたいかなと思いますので、もしご興味あればゆるりと参加していただければと思います。
では今日の朝活はこちらで以上にしたいかなと思います。
はい、お参加いただいた皆さんありがとうございました。
また今日も一日頑張っていきましょう。
ではでは。
