00:07
5月30日、月曜日ですね。はい、時刻は朝9時まいりました。
今日は東京はのぞく晴れていてですね、最高気温30度になるらしいです。暑いですね。
はい、おはようございます。ゆめみのキース孤独あはらです。
では本日も朝活を始めていきたいなと思っております。
はい、では今回もですね、タイトルにある通り引き続き、
React Server ComponentsのRFCをちょっと読んでいこうかなと思っています。
前回で、前回は昨日ですね、モチベーションのところまで終わったので、
続いてディテールデザインというところですね。
詳細な設計というところをちょっとずつ読んでいこうかなと思っております。
ではですね、最初に注意事項みたいなのがちょっと載ってますけど、
そこからぼちぼちとコメントから入っていこうかなと思っております。
まずは注意事項ですね。Reactの開発者の多くというのは、
ここで説明する内容を全部理解する必要はありませんと。
このセクションは主にライブラリやフレームワークの作者を対象としています。
これ自体を使ってアプリケーションを開発する人というよりも、
サードパーティーとかエコシステムとか、ライブラリを作る人たちの読む章だというふうに言ってますね。
では続いて、上記のセクションでは開発者の視点からサーバーコンポーネントを説明しています。
このセクションではサーバーコンポーネントの設計とアプリやフレームワークへの統合方法についてより詳しく説明します。
まず上記のノートの例の簡略化したレンダリングライフサイクルというのを説明していこうかなと思っています。
次に設計の重要な側面についてさらに詳しく入っていこうかなと。
最後に我々が積極的に取り組んでいる未解決の研究分野の概要を説明して終わろうかなと思っています。
では一つ目から行きたいと思いますけど、Simplified Loading Sequenceというところですね。
そこから入っていきたいと思いますけども、このセクションではルートサーバーコンポーネントと子供のクライアントコンポーネントを持つ上記のノートというやつですね。
ノートというのは前回から出てきたノートコンポーネントの略ですね。
この続きを読んでいこうかということですね。
このノートのコンポーネントの例をロードするためのステージを確認します。
これらのステージのいくつかはルーティングとバンドリングの統合を含んでいることに注意してください。
当初の開発者というのはNext.jsのようなフレームワークを介してサーバーコンポーネントを使用すると思われますが、
このフレームワークはデフォルトでこの統合を処理します。
この最初のフレームワークの統合というのは他のライブラリやサーバーコンポーネントのサポートを
自分のアプリケーションに統合しようとしている開発者にとって手本となるものですよというふうに言っています。
03:06
一旦まずちょっと見ましょうか。
The process for rendering for Next.js is roughly as follows.
こんな感じでやりますよと。
まず最初にオンディサーバーなのでサーバー側の方ですね。
サーバー側の方でまず何をやるかというとフレームワークですね。
フレームワークのルーターというのは要求されたURLをサーバーコンポーネントにマッチさせ、
ルートのパラメータをコンポーネントにプロプスして渡します。
フレームワークのルーターは要求されたURLをサーバーコンポーネントにマッチさせ、
ルートのパラメータをコンポーネントにプロプス。
コンポーネントとそのプロプスをレンダリングするようにリアクトに依頼するようと言っています。
この場合はnote.server.jsというファイルになります。
ではリアクト側ですね。
リアクトというのはルートサーバーコンポーネントとサーバーコンポーネントである子供ですね。
子供のコンポーネントをレンダリングします。
レンダリングはネイティブコンポーネント。
ディブとかスパンとかですね。
クライアントコンポーネントで停止します。
ストップと書いてありますね。
レンダリングを一体停止するらしいですね。
ネイティブコンポーネントはUIのJSON技術としてストリームされ、
クライアントコンポーネントはシリアライズされたプロプスとコンポーネントのコードへのバンドル参照を含むストリームとしてストリームされます。
ネイティブコンポーネントはUIのJSON技術として、ここはいわゆる仮想ドームの話かな。
クライアントコンポーネントはシリアライズされたプロプスとコードなので、ここは単なる文字列になっちゃうのかな。
という風に扱うのかなと思いました。
本当にそうなのかわからないし、僕の読んだだけの話なので正しいかわからないですけど。
サーバーコンポーネントが停止した場合ですね。
リアクトはそのサブツリーのレンダリングを一旦停止して、代わりにプレスホルダーの値をストリームすることに注意してください。
コンポーネントが継続できるようになると、いわゆるサスペントが解除されると、
リアクトというのはコンポーネントを再レンダリングして、コンポーネントの実際の結果をクライアントにストリームします。
ターゲットにストリームされるデータはJSONと考えることはできますが、
サスペンドするコンポーネントのためのスロットというものがあって、それらのスロットに配置する値は、
オートストリーム後に追加項目として提供されます。
06:09
ターゲットにストリームされたデータというものはJSONと考えることはできるけど、
サスペンドするコンポーネントのためのスロットがあり、
そのスロットに配置する値というのはオートストリーム後ほど追加項目として提供される。
なるほど。いわゆるスロットの機能ということですね。
フレームワークはリアクトがUIの各ユニットをレンダリングするときに、
レンダリング出力をクライアントに全身的にストリーミングする役割を担います。
ちょっとずつレンダリング出力をクライアントにストリームするんですね。
フレームワークとしては。
デフォルトでは、リアクトはHTMLではなく、レンダリングされたUIの詳細を解説に注意してください。
HTMLではなくてレンダリングされたUIの詳細を解説。
これは新しく取得したデータを終了するクライアントコンポーネントと
マージできるようにするためですよと。
そのためにこれは必須ですと言ってますね。
フレームワークでは、サーバーコンポーネントをサーバーサイドレンダリング、SSRと組み合わせて
最初のレンダリングをHTMLとしてストリーミングすることもできますと言ってますね。
これがサーバー側でやったことですね。
続いて、オン・ザ・クライアントでクライアント側がやることというところですね。
クライアント側ですけども、まずフレームワークですね。
クライアント側でストリームされたリアクトのレスポンスを受け取って
リアクトでページ上にレンダリングしますと。
次リアクトですね。
リアクト側は応答をデシリアライズしてネイティブ要素とクライアントコンポーネントをレンダリングします。
これは徐々に行われますと。
段階だけ行われていくと。
リアクトは何かを表示するためにストリーム全体が終了するのを待つ必要はありません。
サスペンスによって開発者はクライアントコンポーネントのコードがロードされている間や
サーバーのコンポーネントが残りのデータをフェッチしている間に
意図的なロード状態を表示することもできます。
リアクトは全てのクライアントコンポーネントと
全てのサーバーコンポーネントの出力がロードされた後
最終的なUAの状態がユーザーに表示されるようになります。
その時点で全てのサスペンションの境界は既に明らかになっているんじゃないかなという話ですね。
なるほどですね。
サーバー側の方がもう少し触ってみないととか
もうちょっと理解を深めないと
自面だけだとちょっと分からなかったんですけど
わりと細かく配慮していて
裏側とか中身の方は前回も言った通り
シリアライズとデシリアライズを使って文字列化をするとか
09:00
あとJSONで値をほげほげって書いてあったので
多分仮想どもの話だと思うんですけどね
とかをしながら値渡したりなんかしたりとか
ストリームの途中で制御をしたりとかっていう風にやってるらしいですね。
ここで気になってるのはフレームワークっていうワードと
REACTっていうワードですね。
どういうことなのかなっていうのはちょっと気になりましたね。
REACTORフレームワークじゃないのかみたいなのを思いながら
その他のフレームワークってことなのかな
それだとするとREACTとどれだけ優勝するのって感じなので
多分REACT自体の話だと思うんですけどね。
ちょっと僕はわかりませんでした。
続いてアップデートですね。
リフェッチシーケンスの章に入ります。
リフェッチですね。
サーバーコンポーネントっていうのは新しいデータを見るための
再読み込みをサポートしています。
開発者は個々のコンポーネントを個別に取得するわけではないことに注意してください。
これは開始するサーバーコンポーネントとプロプスがあれば
全体を再取得することを想定しています。
最初の読み込みと同様にこれは通常
ルーティングとバンドリングの統合を伴います。
それの詳しい流れを読んでいきますが
クライアントとサーバーはまた同じように行ったり来たりしますね。
まずクライアント側ですけれどもアプリケーションですね。
アプリケーションというのはUIの特定のユニット
例えばフルルート
フルルートって言うと難しいな。
フルルートって書いてあるな。
リフェッチすることを要求します。
全てのルートのところをリフェッチするように要求します。
アプリケーションはですね。
フレームワークはですね。
フレームワークっていうのは適切なエンドポイントから
レンダリング結果を要求することをやっていくよと。
今のがオンズクライアントですね。
クライアント側でまずそのことをやります。
次サーバー側です。
サーバー側では
まずフレームワークですね。
フレームワークのエンドポイントっていうのは
リクエストを受け取って要求されたサーバーコンポーネントにマッチをさせます。
コンポーネントとプロプスのレンダリングをリアクトに依頼をして
レンダリング結果のストーリーも処理します。
リアクト側はですね。
リアクト側は最初の読み込みと同様に
コンポーネントをターゲットにレンダリングをして
フレームワーク側ですね。
フレームワーク側はストリームされたレスポンスデータを
クライアントに順次開始処理も行っていきます。
なるほどね。
ビューとデータを分けてデータを後で配信をしていくってことかな。
12:00
コンポーネントレンダリング自体は先にリアクトに行ってもらって
要はユーザーに早く返そうと。
その後にストリームされた応答を受け取って
データをどんどん返していくと。
クライアント側ですね。続いて。
もう一回クライアント側に戻りますと
まずフレームワークが動きます。
フレームワークはストリームされた応答を受け取って
新しいレンダリングスロックを使用して
ルートの再レンダリングをトリガーしますと。
ルートの再レンダリングをトリガーします。
このルートって言ってるのは
ラウターとかのルートではなくて
そのルートだと思うんですが
英語の方を読んでいくと違いますね。
普通にラウターの方のルートでした。
ルートを先にやるんですね。
続いて
やばい、見失った。どこだ?
クライアント側でフレームワークがストリームされた応答を受け取って
新しいレンダリング
新しいレンダリングスロックを使用して
ルートの再レンダリングをトリガーします。
続いて
REACTっていうのは新しいレンダリングスロックを
画面上の既存のコンポーネントとマージします。
UIの技術っていうのはHDMIではなくてデータなので
REACTは新しいプロプスを既存のコンポーネントでマージして
フォーカスやタイプ入力などの
重要なUIの状態を保持したり
既存のコンテンツでCSSトランジッションをトリガーしたりできます。
これはサーバーコンポーネントがレンダリングされた
UIスロックをHDMIでなくてデータ
いわゆる仮想ドームとして返す主な理由です。
このプロセスの主要な側面については
この後詳しくやりますよと言ってますね。
そういうことをやっているから
状態を保持してきているし
クライアント側の方の
ビューをもう一回再構築できるよと言っているわけですね。
CSSトランジッションのトリガーとかも
また同じようにできるっていうのは結構強いな。
続いて
Capabilities and Constraints of Server and Client Componentsと言ってますね。
続いて続いて読んでいきますが
これ本当にあれですね。
アプリケーション会社側の意識じゃなくて
本当にサードパーティーとか
ライブラリー作成者の事実だというのはよく分かりました。
僕らがこのリアクトを使って
アプリケーションを作るときに
ここまで意識しなくてもいい話を結構しているなと思ったので
かなり根っこの深いところまで話をされているんだなというのは分かりました。
知っておいた上で使うというのも全然いい話であるので
まぁまぁまぁって感じです。
続いて入っていきます。
注意が入りました。
このセクションはちょっと威圧的に感じるかもしれません。
サーバーコンポーネンツを使用するために
15:01
これらのルールをすべて暗記する必要もありません。
.server.jsというファイルと
.client.jsという命名規則に基づいて
これらの制約を強制するための
リントルールというのも用意されています。
はーなるほど。
リアクトサーバーコンポーネンツを使いたい場合は
.server.jsや.client.jsという命名規則が
決まっちゃうわけですね。
リアクトは今までは結構柔軟に
自由な名前付けもできたんですけど
だいぶ名前制約が厳しくなってきた感じですね。
だからよりフレームワーク化してきたとも
言えるのかなと思いました。
レイヤウトの話も近いなと思ったんですけど
あ、でもあれはすいません。
next.jsの話ですね。
これはリアクトの話でした。
まぁまぁ同じような話になるんじゃないかなとは思いますが
で、そのリントルも用意されていて
またリアクトっていうのは何か違反とか
エラーがあった場合は明確なランタイムエラーを出します。
で、ルールのリストはちょっと多く見えるんですけども
直感的にはシンプルにはですよと言っています。
で、クライアントコンポーネンツは
ファイルシステムなどサーバー専用の機能にアクセスできず
サーバーコンポーネンツはステップなど
クライアント専用の機能にもアクセスできない。
クライアントコンポーネンツは
他のクライアントコンポーネントのみを
インポートできるようになります。
本提案で導入された主なコンセプトっていうのは
サーバーコンポーネンツであります。
これに対してクライアントコンポーネンツは
開発者が既に慣れしだしている標準的なリアクトコンポーネントでございます。
クライアントコンポーネントっていう名称には新しい意味は特になく
純粋にサーバーコンポーネンツと区別するために付けられたものです。
このセクションではこれら2種類のコンポーネントの
機能の重要な違いについて説明していきます。
まずサーバーコンポーネンツからですね。
えー、なるほどなるほど。
結構細かく、今からちょっとあれですね。
リスト形式でバーッと書いてあるんですけど、
これは結構細かいですね。
はい。
で、で、で、え、ば、えっと。
読んでいきますか。
ここですね。はい。すいません。
では、えーと、サーバーコンポーネンツからですね。
概念的にはリクエストごとに一度だけサーバー上で実行されるため
状態を使用すること、ステイトを使用することはできませんと書いてますね。
あー、そうなんや。
そのため、ユーズステイトとかユーズリリューサーというのは
サポートされていませんと。
はーん。
はいはい。
で、レンダリングサイクルのエフェクトを使用することもできません。
そのためユーズエフェクトとユーズレイアウトエフェクトも
サポートされていません。
はい。
これがサーバーコンポーネンツの方なんですね。
はいはいはい。
で、えっと、DOMのブラウザー専用のAPIも使用できません。
18:02
ただし、サーバーでポリフィルする場合は例外ではありますけど。
まあでも基本そうですよね。
サーバー側でブラウザ専用の方のAPIというのは
使う必要はないはずなんで、本来は。
はいはい。
なるほど。
でもユーズステイトもユーズエフェクトも
ユーズレイアウトエフェクトもできないっていうのは
ちょっと強いなと思いましたが、
またもうサーバー側で確かに状態を持ってて、
クライアント側の状態を持って、
その状態をちゃんとバンチさせるとかガチャンってやられるのは
結構めんどくさそうなので、
それは正しいもしますね。
はい。
ではここからのリストなんですけど、
できることできないことっていうのがついてますね。
×とチェックみたいなやつがついてるので、
はいはいはい。
ちょっとそれを見ていこうかなと思いますが。
さっきのがその×の一つ目ですね。
はい。
いろんなものは使えませんよーって言ってました。
はい。
で続いて、
状態とか効果に、
効果ってなんだ?
状態と効果に依存する
カスタムフックやブラウザ専用APIに依存する
ユーティリティ関数を使用しないこと。
はい。
これもダメですよーって言ってますね。
ほー。
はいはい。
あ、state or effectsですね。
なるほどね。
今はstate or effectsに依存するようなものとか、
カスタムフックみたいなものを
使用しないように注意してくださいねー
っていう風に言ってますね。
で、えーと、
ここからOKな内容ですね。
OKな内容としては、
いわゆるデータベースであったりとか、
内部のマイクロサービスであったりとか、
ファイルシステムであったりとか、
サーバー専用のデータソースを
使用することができますと。
で、また他のサーバーのコンポーネント、
もしくはネイティブ要素、
ディブスコアなど、
とかですね。
など、
で、またはそのクライアントコンポーネントを
レンダリングすることができますと
言ってますね。
はい。
ほんとになんか、
サーバー専用レンダリングのコンポーネント化した
って感じだ気はしましたね。
で、えーと、
次、サーバーフックスとかユーティリティですね。
はい。
まあ、開発者というのは、
サーバー用に設計されたカスタムフックとか、
まあ、ユーティリティライブラリを
作成することもできます。
はい。
で、サーバーコンポーネントに関する
全てのルールが適用されます。
例えば、
サーバーフックの使用例としては、
サーバーサイドのデータソースに
アクセスするための、
まあ、ヘルパーを提供することも
まあ、あげられますねと。
言いますね。
はいはいはい。
まあまあ、
感情よりまずそこから入っていくのが
いいんじゃないかなという話ですね。
はい。
では続いて、
クライアント側の話ですね。
クライアントコンポーネントの話ですね。
まあでもちょっとさっきので、
まあサーバー側がどういうことなのかって
理解できたのかなと思いましたね。
まあ少しは理解できたって感じです。
で、続いてクライアントコンポーネントですけども、
クライアントコンポーネントは、
標準的なリアクトコンポーネントですので、
これまで使ってきた
全てのルールが適用されます。
主な新しいルールというのは、
サーバーコンポーネントに対して
何ができないかということです。
それはちょっと見ていきましょう。
サーバー上でしか動作しないため、
サーバーコンポーネントをインポートしたり、
サーバーフックとか
21:00
ユーティリティを呼び出したりすることはできません。
サーバーコンポーネント側で持っている機能とか
フックスみたいなのは全然使えません。
ただし、
サーバーコンポーネントは
クライアントコンポーネントの子供として
別のサーバーコンポーネントを
渡すことはできます。
例えば、
クライアントタブバーというコンポーネントの中に
サーバータブコンポーネント
コンテンツみたいなタグが
挟まれていた場合とかですね。
こんなふうな具合で
渡すことはできます。
クライアントタブバーというのは
サーバーコンポーネントで、
クライアントタブバーっていうのは
クライアント側のコンポーネントで、
その子供として
子供として別のサーバーコンポーネントとして サブタブコンテンツみたいな
コンポーネントで挟むこともできます と言ってますね
でクライアントコンポーネントから 見るとその子供はすでにレンダリング
されたツリーサーバータブコンテンツ って今見ているコンポーネント
ですけどもちろん確かにサーバー 側でもすでに処理とかわちゃわちゃ
ってやってることがすべて終わってる はずなので
レンダリングされたツリーになって くれると
それはありがたい話ですよね つまりサーバーコンポーネント
とクライアントコンポーネント はツリーの中でどのレベルでも
ネストさせたりインターリーブ ですかね
介入することができますよって 言ってますね
要はサーバーソースのみのデータ ソースを使用しないってことですね
でもそういうことができるので クライアント側でやるものとサーバー
側でできるものっていうのが実は 統合できるってさっき言ったとおり
だと思いますね よしなに一緒にできるしこちら
側ではすでにレンダリングされた ツリーになっているしこっち側
ではまだまだ今からやりますよ みたいな制御もできたりするとか
ですね 本当状態をもうちょっと細かく
と制御できるようになったっていう 感じに見えました
あとクライアント側でできること としてはステートですね
ユーズステート使えますしユーズ エフェクトとかもできますと
あとはそのブラウザー側のAPIも できますしステートエフェクト
もしくはブラウザー専用APIを使用 するカスタムエフェクトか
ユーティリティももちろん使えます と言ってます
こっちは今までのリアクトと同じ ってことですね
続いてですが今のがキャパビリティ もしくはコンセントレーンズ
オブサーバックアンドクライアント コンポーネントで続いてシェアリング
コードビトインサーバーアンド クライアントですね
コードの共有ってなんだろうな
続いてこのセクションも同じような 注意書きがありますね
言い訳的にちょっと感じるかもし れないですけど
サーバーコンポーネンツを使用 するためにはこれは新しいルール
覚えることはないしほげほげって 言ってます
これはさっきの注意書きと同じ ような感じですね
24:13
どっからだ区切りが難しいな
区切りがないぞ
すいませんちょっとぐだぐだして ますね
インナーディッションがどっか にあったはずなんですけど
インナーディッションが見当たらない
あったはいここですね
ではさっきの注意書きだと読んで たんですけど
多分一緒ですね
クライアントコンポーネントファイル システムをサーバーに載せなき
たあそうですよね
はいっていうところで
続いてインナーディッションっていう ところからですね
純粋なサーバーコンポーネント とクライアントコンポーネント
に加えて
開発者っていうのはサーバーと クライアントの両方で動作する
コンポーネントとフックを作成 することができます
これによってコンポーネントが サーバーコンポーネントとクライアント
コンポーネントの両方の制約を 全て満たしている限り
ロジックを環境間で共有することが できます
したがって共有コンポーネントフック とかはこんな感じになりますよ
というふうに書いてまして
ユーズステイトっていうのが使えません と
ノットユーズって
あとレンダリングライフサイクル フックとか
エフェクトみたいなやつの
レンダリングライフサイクルの フックスも使えませんと
でブラウザーだけのAPIっていう のももちろんできません
あとカスタムフックスとかユーティリティー ですね
ステイトとかエフェクトとか
そのブラウザーのAPIに依存した ような
カスタムフックスとかでユーティリティー ももちろん使えませんと
あとサーバーサイドのデータソース ももちろん使えませんと
あとレンダーサーバーコンポーネント とか
ユーズサーバーフックスみたいな サーバー側のフックスみたいな
やつももちろんできません
要はクライアントとサーバーで ちゃんと責務を分けてます
っていうことですね
でやれるのは本当にサーバーアンド クライアントでの
コードの共有のところですね
でこの具体的にどういうことが できるのかっていうのが
まだ書いてないな
これだけだとわからないんで
それがこの下に書いてあるのかな
ちょっと読んでいきます
共有コンポーネントですね
共有コンポーネントには多くの 制約がありますが
実際には多くのコンポーネント が
すでにこれらの規則に従って
サーバーとクライアントの間で 修正せずに使用できることが
もうすでに分かっていますと
おおそうなんや
多くのコンポーネントはその状態 を使ったり
追加のデータをロードすること なく
いくつかの条件に基づいて
いくつかのプロプスを単に変換 するだけでいいと
これが共有コンポーネントが デフォルトであり
特別なファイル拡張子を持たない 理由ではあります
ああなるほどですね
特別何かすることがないから かもしれないな
27:01
共有コンポーネントの典型的な 例としては
例えばマークダウンレンダラー のようなものになりますと
マークダウンで書かれたコンテンツ を見るためのルートをロードする場合
編集はしない場合ですね
サーバー上でマークダウンを レンダリングする方が効率的であり
クライアントに巨大なマークダウン のレンダリングライブラリを
ダウンロードする必要はありません
しかしユーザーがコンテンツを 編集したい場合
マークダウンライブラリはオンデ バンドでダウンロードされ
ユーザーが編集している間ライブ プレビューを提供することができます
共有コンポーネントを使用する ことで
アプリケーションはこのレンダリング のための単一の真実のソースを
持つことができます
この辺は前回までに見てきた話 と
結構似ている話かなと思いました
思い処理は結局サーバー側に寄 せていくけども
クライアント側で必要なものは ちゃんと
必要な分だけちゃんと対応できます よということですね
それを共有コンポーネントという ところで対応できるようになって
いくと
これはでもいい話ですね
クライアントとサーバー側で別々 にちゃんとコンポーネント書いて
わちゃわちゃってやるのかなと思 ったら
共有のコンポーネントでいけます よと言ってますね
ラストがまた長いですね
ネーミング&コンベンション for サーバークライアントコンポーネント
って書いてるんで
名前についての話を最後にする そうですね
読んでいきたいんですけどもう ちょっと30分過ぎてきましたし
ここの次の話がまたちょっと長い ので
ここで区切ろうかなと思います
明日はもうちょっとリアクトの サーバーコンポーネントの話続き
を読んでいって
明日はでもですねさっきの言った ネーミングのところと
あとドローバックスオルタネイティブ アダプションストラテジーとか
ハウイティッチディスクレジット アンド
クレジットのとこは別にって感じ かな
最後FAQがあるんでFAQをパパパパ っと読んでいく感じになるかな
と思いますね
FAQもかなり長いんでどこまでいける かわかんないですけど
はいちょっと明日ももしかしたら 明後日まで続くかもしれないですよ
ね
はい
アダプションストラテジーとか その細かいところはちょっとじゃあ
あの端折るかもしれないですね
はい
というところでじゃあ今日は朝 合わせこちらで以上にしたいかな
と思っております
はいまあ月曜日の朝イチってところ でも
ちょっと眠いんですけども
はいまあ今週もちょっと頑張って いきたいと思います
はい
まあ暑いですけどね皆さんも体調 に気をつけていただければなと思います
ではでは今日も頑張っていきましょう
おつかれさまです
