00:06
はい、5月29日、日曜日ですね。朝木9時の7分まで待ってしまいました。すみません。
ちょっと寝坊してしまいましてですね。バタバタとまた準備してます。かなり眠いですけど。
はい、おはようございます。ゆめみのキースからですね。では本日も朝活を始めていきたいと思います。
はい、タイトルにある通り、前回同様、React Server ComponentsのRFCですね。この続きを読んでいこうと思っています。
だいぶ長いんですけども、ずっとやっていこうかなと思います。
昨日は、サマリーと基本的な使用方法の話までちょっと入って、
今日はですね、続きですね。モチベーションまで入りましたね。
モチベーションで、まずゼロボンドルサイズコンポーネントというところと、フルアクセストゥーザパックエンドの話までちょっと入っていましたね。
で、次はノークライアントサーバーボータホールズのところまで入りたいと思っていたんですけど、
昨日は時間がなかったので、そこでストップしてしまったという感じですね。
なので今日はそこから入っていきたいと思い、あ、違うわ。すいません。間違えましたね。
オートマティックコードスプリッティングの続きからやっていきたいと思います。
はい、今回もソースコードがダラダラ書いてあるので、
後頭での説明でちょっと難しくなってしまうかもしれないんですけど、やっていきたいと思います。
今日はですね、7分までオーバーしてしまったので、そのまま後ろ倒しで9時37分というちょっと中途半端な時間までですけど、
やっていきたいかなと思います。
ではオートマティックコードスプリッティングですね。
自動的なコードスプリッティング、コード分割というところから入っていきたいと思います。
リアクトというのをしばらく使っていると、コード分割の概念に馴染みがあるかもしれません。
リアクト内にしても、Vueもそうですし、Splitもそうですけど、
いわゆるUIフレームワークみたいなライブラリというのを使うと、馴染みがあるかなと思いますね。
こちらは開発者がアプリケーションをより小さなバンドルに分割をして、
クライアントに送信するコードというのを少なくすることを可能にしますよと。
一般的なアプローチというのは、ルートごとにバンドルを遅延ロードしたり、レジローディングですね。
実行時に何らかの基準に基づいて異なるモジュールを遅延ロードしたりすることですと。
はい、ご参加いただきありがとうございます。
タイトルがある通り、リアクトサーバーコンポーネントのGitHubにあるRFCですね。
モチベーションの章に入って、今はオートマティックコードスプリッティングに入ったところですね。
本題に戻りますね。
今言った通りです。
実行時に何らかの基準に基づいて異なるモジュールを遅延ロードしたりするようなことということですね。
これが一般的なアプローチなんですけど、
例えばアプリケーションというのは、ユーザーとかだったり、コンテンツであったりとか、機能フラグだったりとかに応じて、
03:01
異なるコードを異なるバンドルで遅延ロードすることができますと。
でもそれの例として、ソースコードで読んでいきますね。
例えばphotorender.jsというファイルがあったとしましょう。
これはサーバーコンポーネントを使わない場合のソースコードですね。
あったときにクライアント側でoldphotorender.jsとかnewphotorender.jsみたいなところを
react.lazyにかけて遅延ロードしたとしましょう。
そのコンポーネントを読み込んで、それを最終的に本来のコンポーネントですね。
ファンクション関数コンポーネントで定義してあります。
photoという名前の関数コンポーネントを定義して、
ifフィーチャーフラグで新しい方のphotorenderを使いたい場合は、
先ほど読んだnewphotorenderというコンポーネント、
古い方を読みたければoldphotorenderというコンポーネントを
returnで返してあげれば、一応この関数コンポーネントとしては動きますよと。
従来はそうやって状態だったりフラグだったりした条件分岐で
表示をしていましたというやり方ですね。
従来というか今も絶賛そういうやり方をしていますし、
各種フレームワークそんなような感じだと思います。
コード分割というのはパフォーマンス向上に役立つんですけど、
既存のコード分割のアプローチには2つの制限があります。
1つ目、開発者というのは通常のインポート分をreact.lazyというメソッドと
ダイナミックインポートに置き換えてそれを行うことは覚えておく必要があります。
2つ目はこのアプローチでアプリケーションが選択したコンポーネントの
ロードを開始できる時点が遅れて、ロードするコードが少ないという利点の
一部が相殺されてしまいますよと言っていますね。
ちょっとこれ翻訳的に、さっきのやつに2つを書いていて
それの説明をしていいみたいな感じのような気がしますけど、
確かにそうですね。
ロードを開始する時点が遅れるのでコードが少ないという利点は
一部確かに相殺されてしまいますよね。
結局ユーザーにパッと早く返してあげて
操作をブロックさせないというのが大事ですからね。
サーバーコンポーネンツというのはその2つの方法で
これらの制限に対処していきますよと言っています。
まずいわゆるコードの分割を自動的に行ってくれるようになります。
サーバーコンポーネンツというのはクライアントコンポーネンツの
すべてのインポートをコード分割の可能性がある
ポイントとして制御できます。
第2に開発者がどのコンポーネントを使用するかを
サーバー上でより早く選択できるように
クライアントがレンダリングプロセスの早い段階でダウンロードできるようにします。
その結果サーバーコンポーネンツというのは
開発者がアプリに集中し自然なコードを書けるように
フレームワークがデフォルトでアプリの配信を
最適化するようにしてくれます。
またソースコードの例が出てきます。
06:02
先ほどのphotolender.jsを
サーバーコンポーネンツで書き換えていくと
photolender.server.jsという風に
ファイル名を書き換えまして
どうやってやるかというと最初にimport reactをします。
先ほどと同じようにoldphotolenderと
newphotolenderのclient.jsというファイルですね。
クライアント側のコンポーネントを
importします。
同じように関数コンポーネントファンクションで定義して
関数名はphotoですね。
引き続きプロプスを受け取っています。
書き方としてはさっきと全く一緒です。
条件分岐をしています。
フラグの値を見て新しいほうだったら新しいほうのphotolenderの
コンポーネントで古いほうだったらoldphotolenderの
コンポーネントをreturn.jsで返してあげればよいと
言っています。同じようにやってるんですけど
コードの違いとしては
ないんじゃないかこれ。
実は。
厳密に言うとserver.jsというファイルと
client.jsというファイルに書き直している
ぐらいで
先ほどはreact.lazyにかけてたんですけど
今度は別にlazyにかけてないですね。
なのでimport fromで読み込んでます。
先ほどは確かにconstイコール
ダイナミックインポートにさらにreact.lazyにかけてましたけど
今回はそんなことせずに単純にimport fromでやってますね。
これだけでコードのスプリッティングを
やってくれたり最適化したりとか
自動化してくれたりとか
いうのをやってくれるそうですね。
まだフワッとしてるとか抽象的すぎて
ここら辺は実際に書いてみないとなんとも言えないっていうのもあるし
実際にアプリケーションでやってみないと難しいところもあるんですけど
とにかく自動でやってくれるってことは
なんとなく見て取れることは分かりましたね。
これは後ほどのRFCがしっかり
実装のチケットになってリリースされてから
確認したいかなと思いましたね。
では続いていきましょう。
ではまた
だらだらと読んでいくので翻訳をしますが
パフォーマンス低下の一般的な原因というのは
アプリケーションがデータを取得されるために
連続した要求をするときに発生します。
例えばデータ取得のパターンの一つに
最初のプレスフォルタをレンダリングして
その後にユーズエフェクトフックでデータを取得するものがあります。
一般的な感じですね。
これも例として関数コンポーネントで
ノートというコンポーネントを定義しておきましょう。
ノート.jsというファイルがあって
ファンクションノートで引数にプロプスを受け取っていると。
コンストでユーズステートですね。
09:00
最初は初期値にヌールです。
ノートとセットノートというセッターと変数で
リスポンスを受け取っています。
第2引数にコールバック関数を定義していまして
第2引数はプロプス.idが第2引数ですね。
だからidが変わったら取得するノートの詳細記事が変わってくるので
それごとにユーズエフェクトで走らせて
データを取ってきているという感じですね。
そのユーズエフェクトの中の方で
フェッチノートみたいな関数がもしあったとして
それにプロプス.idを引数として渡してあげると。
プロミス.idは
プロプス.idを引数として渡してあげると。
プロミス.idで返ってくるような感じで扱っています。
ドット全で受け取ってデータをセットノートで
走らせて
ステート管理をしていますという感じですね。
シンプルな例です。
もしノートがヌールであった場合ですね
リスポンスを受け取ったノートがヌールだった場合は
まだ取得中のはずなので
ストリングスを返します。
もしノートがヌールじゃなければリターンで
レンダリングの処理を走らせようということですね。
レンダリングの処理を走らせようということですね。
というのが
ノート.jsというコンポーネントなんですけども
これをサーバーコンポーネンツにかけてる場合
どうやっていくのかみたいな説明が
下に続きますね。
コメントからいきますと
親コンポーネントと子コンポーネントの両方が
この方法を使用する場合
親子で同じようなものを使う場合は
親コンポーネントのデータを読み込みが終了するまで
子どもの方はデータの読み込みを返せることはできません。
それは確かに同じことを言ってますね。
これには良い面もありますと
それぞれのコンポーネントでデータを取得することの利点というのは
アプリケーションが必要なデータだけを
取得して
アプリケーションが必要なデータを
そのコンポーネントごとに取得して
レンダリングされてないUIの部分に対するデータの取得を避けることができますと
ちゃんとスコープ切ってデータを取得して
扱うことができますよねと
我々はクライアントからの連続したラウンドドリップを
回避しながら使用されてないか
データの過剰フェッチを回避する方法を見つけたいと思いました
今の状態はそれで別に悪くはないんだけど
結局ブロックしてしまう問題があるので
回避できる方法がないかなというのを探していました
サーバーコンポーネンツというのは
シーケンシャルなラウンドドリップをサーバーに移すことで
アプリケーションがこの目標を達成することが可能にします
フェッチングのところもサーバー側に
処理を委託するということかな
問題はラウンドドリップではなくて
クライアントからサーバーへのラウンドドリップであることです
12:00
なるほどね
そういうことが着目点だと
このロジックをサーバーに移動することでリクエストのレイテンシーを減らして
パフォーマンスを向上させることができるようになります
クライアント側からじゃなくてサーバーから全部リクエストやってくれるんだったら
レイテンシー減りますもんね
さらにサーバーコンポーネンツでは開発者は
最小限のデータをコンポーネンツ内から直接取得し続けることができます
そうですよね
しかも直接できるというのは結構でかいですね
同じようなさっきの例をサーバーコンポーネンツを使った場合の
ソースコードが出てきます
同じようにサーバーコンポーネンツなので
note.server.jsというファイルに切り出して
同じように関数コンポーネンツとして定義しますね
function noteでプロプスを受け取ってます
それを受け取って
最初にconstでnoteという変数を定義しておいて
db.notes.getみたいな
引数のプロプス.idを渡してあげて
データを直接取りに行くという感じですね
これは昨日まで読んでいた範囲の中に
dbというようなインスタンスがあるんですけど
これはサーバー側からデータを取ってきた
ものを扱っているインスタンスですね
それがあるのでその中にnoteというものがあって
そこのデータを欲しいから.getでアクセスをしている
というような感じになっています
実際にソースコードとかを見てもらったほうが
早いかもしれないです
サーバーコンポーネンツのほうで既にデータを持っていて
それにアクセスするためのメソッドが用意されてますよ
ぐらいの感じで思っていただければと思います
データを受け取るときにプロプスが受け取ったidを
渡してあげているという感じですね
もしnoteがヌルだったらまた同じようにミスティングの
処理をしてnoteが取れているデータがあるのであれば
renderでjsxでレンダリングしていけばいいよ
というような処理をしています
結構シンプルになりましたね
わざわざユーズステートとかユーズエフェクトとかを
わーって書いていたものをサーバー側に移行していって
サーバー側のほうでデータを持っているんだったらというような
クライアント側はその最後データだけを受け取って
レンダリングするだけというシンプルな構想になりますよね
これはサーバーコンポーネントのまさに
一大メリットの一つかなと思います
ウォーターホールの話も最後に言及して終わりますが
ウォーターホールはサーバー上ではまだ理想的とは言えないので
最適化してデータ要求をプリロードするAPIを
まだ提供する予定ではあります
しかしクライアントサーバーのウォーターホールは
特にパフォーマンスが悪いのでそれを気にする必要がないことは
重要な利点であるというのは考えていますよという感じですね
もうちょっとウォーターホールのところについては
設計を考えていきたいというところらしいですね
だいぶサーバーコンポーネントという機能だけでも
パフォーマンス改善であったりとか
サーバー側に処理をどんどん委託できるようになるという
15:01
メリットが本当に大きいと思うので
それだけでも今のウォーターホールは維持したまま
パフォーマンスコンポーネントを導入するだけでも
僕らとしてはかなりメリットが大きいと思いますね
ただその間にソースコードがちょっと増えていくと思いますね
やっぱりサーバーとクライアント側で明確に
ここの処理はクライアントここの処理はサーバーと分けなきゃいけないので
ファイル数とか処理は増えますけど結果的に
レンダリングするときのパフォーマンスが下がるので
ユーザーのパフォーマンスが上がるという意味では
全然いい話だと思っていますので
APIコールしてレンダリングするまでの処理が
そんなに時間かかんないとかスパッといくんであれば
僕はそれはそれであれだと思います
コードの統一性というのがその代わり崩れていくのも別の問題であると思うので
この辺は設計どうするかというのはチームであったり
皆さんの方で考えていかなきゃいけないというのは思いますけど
本質的にはクライアントユーザーに対して
どういう体験をさせるかというのが結構課題になると思うので
統一性がないにしても何にしてもいろいろルールを決めて
それをドキュメントにしっかり落としておくというのが
最終的に必要になってくるなという気がしています
これは本当にいい話なので
リアクトのサーバーコンポーネンツというのは去年おととしかな
ワードだけ聞いたんですけど全然放置してたんですけど
これかなりいいですね
もうちょっと追っていきたいというかリアクトのこの
サーバーコンポーネンツ機能がちゃんとリリースされたときに
しっかり触ってみたくなりましたね
これがノークライアントサーバーウォーターホールズというところの
モチベーションでした
続いてのモチベーションは
アボイディングザ・アブストラクションタックスということですね
どういう翻訳になるんだこれは
抽象化を回避するそのままだと
同じことを言ってるかわかんないけどしっかり読んでいきましょうか
リアクトっていうのは
テンプレート言語ではないと
少なくともテンプレート言語ではありませんよねと言ってます
開発者っていうのは関数の合成であったりとか
リフレクションなどの言語機能を使用して
強力なUIの抽象化を作成することができますよと言ってますね
しかしこれらの抽象化を使いすぎてしまうと
より多くのコードと実行時のオーバーヘッドという
対象を支払うことになります
性的な言語ですねUIフレームワークの
性的な言語というのは
書き読みのコンパイルを利用してこれらの抽象化の一部を
コンパイルで取り戻すこともできますけどJavaScriptで
このオプションは利用できませんよと言ってますね
これはJSの限界というか仕方ない面ではありますね
この課題に対照するために
我々は当初先行時間型
いわゆるAoTの最適化の一つのアプローチである
プリパックの実験を行っていました
プリパックという名前は僕は全然存じ上げなかったんですけど
そんなものがあったんですね
いわゆるAoTの最適化のためにプリパックという実験を
18:02
最初はやってたんですね
最終的にそれはとんざしたとかうまくいかなかったらしいですね
具体的には多くのAoT最適化がうまくいかないというのは
グローバルの知識が十分じゃないもしくは少なすぎるであることに
気づきましたと
グローバルの知識というのは具体的に何の知識なのかが
また出てくればいいんですけどちょっとわかんないですね
例えばあるコンポーネントは親から常に一定の文字列を
受け取るので
実際には静的に見えるかもしれませんが
コンパイラーはそこまで見えないので
そのコンポーネントを動的だと考えてしまいます
僕ら勝手じゃなくて機械がそのグローバルの知識が
十分じゃないもしくは少なすぎるため
という風に言っているように聞こえますね
これがうまくいったとしても開発者にとって予測不可能なことが
わかりました予測不可能な最適化というのは
開発者にとってももちろん信頼はしがたいものですよね
なるほどねそういうことか
最終的にこれが静的かどうかなんて機械には
わかり得ないですよね
オプションがあったりとかそういうことをこれは静的ですよ
って指定するものがあるんだったらいいですけど
それをコンポーネント単位とかでガチャガチャやるなんて
僕らの体験も悪くなるし本質的ではない気がしますので
仕方ないよねっていうのはあるけど
それにでもちゃんと面と向かってアプローチしていこう
ということらしいですね
サーバーコンポーネントですね
サーバーコンポーネントというのはサーバー上の中小化コストというのを
取り除くことでこの問題解決するために役立ちます
例えば設定可能なラッパーを何重にも重ねたサーバーコンポーネント
というのが最終的な単一の要素に連打リンクされる場合ですね
っていうのはクライアントに送信されるのはその要素のみになります
そうですね確かに
次の例ではそのノートっていうのを
中間的なノートウィズマークダウンっていうものを作って
それの中小化を利用してリブをラッピングして
レンダリングするためリアクトはディブ
およびそのコンテンツだけをクライアントに送信します
というような例をやっていきます
じゃあソース広報ですのでまた
同じようにサーバーコンポーネントなので
まずノート.サーバー.jsですね
いろいろインポートして関数コンポーネントを定義します
function noteで今回引数に文字列を展開して
idっていう引数を受け取ったとしましょう
別にprops.idでもいいんですけど
今回は明示的にidっていう展開で受け取ってます
同じようにconstでnoteっていう変数を持っておいて
db.notes.getで
引数にidを出してあげます
そのidのノート情報や記事の詳細情報を受け取ってます
で、リターンで
note-with-markdownっていうコンポーネントに
引数でノート情報っていうのを渡してリターンしてます
で、もう一個
note-with-markdown.server.jsですね
先ほど読み込んだコンポーネントです
21:02
こっちも同じように関数コンポーネントで定義をして
note-with-markdownっていう名前で定義します
引数は先ほどnoteっていうプロプスで渡してるので
こちらもnoteっていうプロプスキーで
受け取ってますね
こちらも別にプロプスで受け取ってもいいけど
文字列展開でnoteっていうので受け取ってます
note-with-markdownの方では何やってるかっていうと
markdownをやるので基本的にサニタイズをしなきゃいけない
サニタイズのライブラリを読み込んだ前提で書かれてます
const html イコール
sanitize htmlっていうメソッドがあって
その中にmarkdownのデータですね
note.txtっていうのがプロプスの変数の中にあるらしいので
そのnote情報っていうのを
sanitize.htmlっていう関数にかけて
変数.htmlで受け取ってます
最後にリターンでdivでホゲホゲっていうのを
レンダリングしたものをリターンしてます
すでにサニタイズしてますしデータの取得もできてます
といったものをただただ表示するだけになるので
クライアントの方はdivで中身
markdownのアウトプットがドーンと出てくるだけに
できますよねっていう風に言ってます
コンポーネント自体も何重になってしまったりとか
ネストすることがあったとしてもそれもサーバー側に寄せることで
クライアントの方ではやはり来たものを出すだけに
できるっていうのはシンプルになるよってことで言ってますね
これはありがたいですね
本当はクライアントの方でもわちゃわちゃやることは絶対あると思うんですけど
結果データ取得した後に
わちゃっと計算したりとか処理変換したりとか
いろんなことをやった最後のhtmlですね
連打にされたリアクトのコンポーネントのhtmlっていうのを一つだけバーンと受け取って
それをクライアントのリアクトがガンって出すだけっていうのは
ものすごくシンプルでいいなと思いますので
その辺も全部サーバー側に寄せられるんだったら結構未来があるなという
僕も感じましたね
今のがアボイディング・ザ・アブストラクションタックスですね
最後モチベーションのラストですね
ディスティンクト・チャレンジズとユニファイド・ソリューションですね
異なる課題と統一された解決策だよっていう話です
最後このモチベーションはソースコードなくて
単純にテキストだけなんでまずダラッと読んでいきたいと思います
前述の通り
これらの課題のテーマっていうのはリアクトが主に
クライアント中心であることでした
PHPとかRailsなどの伝統的なサーバーレンダリングを使用する
そのようなフレームワークを使う場合は
確かにこれらの課題のいくつかに対処する一つの方法ではもちろんありますが
そのアプローチでは
リッチでインタラクティブな体験を構築することが
はるかに難しくなりますよね
やり方だとクライアント側に割と
そのフレームワークの依存があったりとか制限があったりとかするので
リッチなの意外と作れないよねっていう
24:01
作ることは頑張ればできるかもしれないですけど
開発者が苦しむので結果的に問題解決にはなっていない気がします
これでは
Web以前のアプリケーション開発の世界になってしまって
新クライアントっていうのを使うかシッククライアントを使うかみたいな
長年の緊張関係が反映するようになってしまいますよね
新クライアントとシッククライアントっていう
僕はワードを知らなかったんですけど
そういう表現の仕方があったんですね
最終的に我々というのは純粋なサーバーレンダリングと
純粋なクライアントレンダリングのどちらか一方だけでは
不十分であることに気づきました
やっぱりそうなりますよね
サーバーレンダリングっていうのはアプリケーションが
サーバーサイドのデータソースに簡単にアクセスできて
一方クライアントレンダリングっていうのはユーザーが即時の
フィードバックを期待するリッチで
インタラクティブな機能には欠かせないものであります
2つの言語でコードを書き2つのフレームワークを使って
2つのエコシステムを念頭に置くことになります
また言語間のデータ転送に対処する必要があって
サーバーレンダリングのビューとインタラクティブな
クライアントプレビューのロジックを重複させる必要がある場合も少なくはありません
これは仕方ないですよね
サーバー側とクライアント側で分けるっていう風に言うんであれば
同じリアクトを使うかもしれないですけど
サーバー側のコードとクライアント側のコードをしっかり厳密に分けますし
2つのフレームワークを使うってのはよく分からないですけども
2つでイディオムとかエコシステムとかも若干違いますよねってのはあって
それはそうだよなと思ってます
サーバーコンポーネントを使用すると
リアクトアプリっていうのは単一の言語もちろん単一のフレームワークを呼べ
APIとイディオムの凝縮セットを使用しながら
クライアントとクライアントの両方のレンダリングの長所を得ることができます
昔はそうやってあるか
クライアントはリアクトでサーバー側はPHPとかレールズとか
フレームワークも確かに2つあったし
それぞれのエコシステムに依存しなきゃいけないし
だけどそれをリアクトを使うと1つでやれちゃいますよってことですね
リアクトがUI側クライアント側のフレームワークではなくて
本当にアプリケーション全体としてのフレームワークを
カバーできるようにもう少し
全体といっても完全にAPIとかまでリアクトが担当するという意味ではないですけど
もちろんAPIでちゃんとサーバー側が作ってくれればいいんですけど
データのところをリアクトが依存だと
来たものをただ出すだけっていうところから
本当に来たものの来るところまでアクセスをして
そこら辺も吉田にやってくれるようになるというのが
大きな違いになるというところですね
取得周りは今までクライアント側は基本雑だったというか
何も考慮しないでとにかくAPIの仕様に従ってやらなきゃいけなかった
なのでAPIの仕様としても結構大事ですし
APIチームとのコミュニケーションもいっぱいあったというのは
今もいろんなところで起きていると思いますけど
そこにもう少し介入できていて
27:01
クライアント側が本当にやりたいこと
本来実現したいことにもう少し注力できるようになるというのは結構大きいですね
なった時にちょっと前に流行った
バックオブフロントエンドとフロントオブフロントエンドという
フロントエンドエンジニアの区分けがあったと思うんですけど
あれがもう少し意味を成してくるというか
必要性が出てくるのが分かったと思いましたね
同じリアクトを各にしてもやっぱりバックオブフロントエンドの人たちが
リアクトのサーバーコンポーネンスの方のチケットとかを
担当するようになるんじゃないかなと思ったりしますね
もちろん両方できるようにこうしたことはないし
ただ明示的にそこを分けるというので役割担当を分けて
スキルを伸ばしていくというのも全然この先
何か出てくるんだろうなというふうに今思いましたね
余談が過ぎたのでもう一回戻りますね
我々はまだサーバーコンポーネンスのデザイン空間を
完全に探求している途中ではあるんですけど
最初のプロダクションインディグレーションを既に出荷していて
さらにいくつかのオープンな研究領域を積極的に探求しています
サーバーコンポーネンスのハイレベルな設計を
この後以下に説明していきますよと言っていますね
現状まだ捕捉している途中ではあるんですけど
現状の設計周りのところの詳細を
ガーッと説明していきたいなというふうにお話しています
この先もひたすらずっとテキストがパッと続くんですけど
また凄まじい長さですね
一応モチベーションの話は今ので以上で
ここからはディテールデザインというので
詳細設計の話についてガッと入っていきたいなというふうには思っていますが
時間もちょっと過ぎてきたので
今日はこちらで以上にして
また明日からリアクトのサーバーコンポーネンスの
設計の詳細について入っていきたいなと思います
一応注意書きだけパッと読んで終わろうかな
注意としてリアクトの開発者の多くっていうのは
ここで説明する内容の全てを理解する必要はもちろんないですよと
このセクションは主にライブラリやフレームワークの作者を対象としています
リアクトのユーザー側というよりも
ライブラリやフレームワークのエコシステムが
サードパーティーの作者の方かな
を対象しているようなお話っぽい気がします
サーバーコンポーネンスのところガッツリ使うのは
そっち側の人な気がしますので
一応でもそれサーバーコンポーネンスの設計の話があるので
その辺もちょっと来週
明日から読んでいきたいかなと思いますので
今日はこちらでダラダラですけど
朝から以上にしたいかなと思います
ご参加いただきました
アズさんありがとうございました
日曜日ですのでゆっくりと休んでいただくなり
休日を過ごしていただければなと思います
では以上にしたいと思います
お疲れ様です
