00:07
5月31日、9月1日、9時1分ですね。
今日の東京は、あいにく天気が雨っぽいですね。
曇りのと雨が混ざっています。
おはようございます。ゆめみのキース孤独は原です。
では本日も朝活を始めていきたいなと思います。
ではですね、昨日に引き続き、今日もRFCですね、React Server ComponentsのRFCを
ちょっと続きを読んでいこうかなと思っています。
ちょっと今日で頑張って終わらせていきたいなと思っていますので。
昨日までで、ディテールデザインですね、詳細な設計のところの話の
ネーミング・コンベンション・フォーサーバー・クライアント・
コンポーネンツのところまで読んだので、続いて
オープン・エリアス・オブ・リサーチというやつのところまで
いっていきたいと思います。
最初にまたコメントがあるので、そこからですね。
サーバー・コンポーネンツの重要な基本事項の多くを把握し、
実運用に向けた実験を開始しておりますが、
まだ研究を続ける領域がいくつかあります。
今後もこのような分野を洗い出しながら、
情報を共有していきたいと思います。
ここですね。
大地さん、おはようございます。
今日もダラダラとRFCのReact Server Componentsを読んでいます。
このオープン・エリアス・リサーチのところですが、
結構長いので、音訳に時間がちょっとかかりそうですね。
実に1、2、3、4、5、6、7項目に分けてコメントがありますので。
にあるさん、おはようございます。
朝霞さん、ご参加いただきありがとうございます。
タイトルにある通り、React Server ComponentsのRFCを
ダラダラと読んでいる感じです。
今日はオープン・エリアス・オブ・リサーチですけど、
一つずつ読んでいきたいと思いますが、
まず開発者ツールで、デベロッパーツールですね。
我々はサーバー・コンポーネンツを含むReactの機能を
正式にリリースするためには、
ファーストクラスの開発者ツールが必須条件であると考えています。
ファーストクラスっていうのは、
どういうカテゴリーかちょっとわからないですけど。
我々の目標は、サーバーとクライアントにまたがる
Reactアプリを書くために統合された
開発者エクスペリエンスを提供することです。
例えば、コンポーネントインスペクターに
サーバー・コンポーネンツの階層が表示されていても、
実際にはそのコンポーネントが
クライアントツールに存在しないことがあり得ますと。
同様に開発者っていうのは、
サーバーのエラーやログが
クライアントの開発者コンソールに表示され、
クライアントのソースペインから
サーバーのコードをブレイクポイントできることが理想的です。
そうね。
サーバー・コンポーネンツっていうのを作って
サーバー側に処理を押し付けたけど、
できれば僕らはフロント側の方で
ログとかエラーが見れた方がやっぱりいいですよね。
我々はこのようなアイデアを人工工学的かつ
安全な方法で実現するためのアプローチを
積極的に今検討しているということだそうですね。
これはありがたい。素晴らしいですね。
続いてルーティングです。
03:01
ルーティングは前述の通り、
一般にアプリケーションではページの要求を
特定のサーバーコンポーネンツのレンダリング要求に
マッピングをして、そのレンダリング出力を
クライアントに送信して最終的に表示するために
ルータとの統合が必要になります。
そうね。
最初のリリースではサーバーコンポーネンツを
一つまたは複数のフレームワークに統合することを計画していて、
そのフレームワークというのは
他のルーティングの統合方法のガイドとして機能します。
この最初のフレームワークの統合の一部として
ルーティングがどのように機能するかの
未解決な問題を探りますと。
この言っている一つまたは複数のフレームワークに
統合するということですけれども、
このフレームワークというのは何を指しているのか
いまだに分かっていなくてですね、僕は。
リアクトではないんだろうなというのはよく分かるんですけれども、
その他エコシステムがサードパーティーのフレームワークと
うまいこと連携するということだったら
全然大きい話になるんですけれども、
ただリアクトだけがサーバーコンポーネンツを提供するのではなくて、
他のフレームワークでもサーバーコンポーネンツが実装されると
それはそれでまた面白い話だなと思っていますので。
まだちょっと憶測の意見は出ないですけれども。
では続いてバンドリングですね。
サーバーコンポーネンツというのは
クライアントがCDNなどの静的リソースサーバーから
適切なバンドリングを取得するために
必要な全てのメタデータを含む
クライアントコンポーネントを動的に送信できなければなりません。
いいですね、ちゃんとメタデータとかも考慮しているんですね。
サーバークライアントコンポーネンツの命名規則で述べたように
バンドラーは.server.jsというものと
.client.jsというファイルに関する規則や
その他のサーバーコンポーネンツ固有のパッケージJSON規則を
理解することも必要です。
この領域はWebpackやParselなどのプロジェクトと協力して
私たちが積極的に調査している領域です。
WebpackはわかるけどParselとも連携しているんですね。
今はビートが流行ってきているので
ビートとも連携してもらえた方がちょっと嬉しいかなと思ったりしますね。
多分やってると思いますけど。
この調査には最も効率的なバンドル占領を見つけるための
様々なヒューリスティックの研究も含まれていますということでした。
いい話ですね。
続いてPageNationと
パーシャルリフェッチだから部分的なリフェッチですね。
上記の更新、リフェッチのシーケンスに述べたように
ページを再読み込むする際の典型的な方法というのは
ページを完全に再読み込むすることです。
まあそりゃそうね。
しかしPageNationなどこれが望ましくないケースもあります。
理想的にはユーザーがその時点までに見たすべてのアイテムを
再読み込むするのではなく
次のN個のアイテムのみをフェッチすることですと。
サーバーコンポーネンツでページ処理をどのように
モデル化するのが最適かも現在も研究中ですと。
例えば内部的にはサーバーコンポーネンツを
GraphQL経由でロードして
サーバーコンポーネンツのページネーション不足化を回避するために
GraphQLのページネーション用の既存のインフラストラクチャを
06:00
使用していますとか。
しかし我々はこのユースケースのために
リアクト内で一般的なソリューションを開発することを
やっぱり専念していますと。
いいですね。
はい。
本当に夢のような話ばかりしているけど
そこを本当に実現できるのかというのはありますが
でもできたらできたで
よりリアクトの人気が上がるんだろうなという感もあって
さてさてというところですね。
はい。では続いてミューテーションと
インバリデーションですね。
日本語ですると変異と無効化って読めますけど
ちょっと悩ましい翻訳だなと思うので。
はい。で、こちらです。
最初のデモでは更新が発生するたびに
キャッシュされたサーバーコンポーネンツを
すべてクリアしていますと。
これは多くのアプリでうまく機能する
シンプルなアプローチではありますが
アプリによってはより洗練された無効化戦略というのが
必要になる場合がありますと。
我々はより細かいキャッシュ
無効化のための汎用メカニズムを
サポートする方法と
楽観的なミューテーションというものを
サポートするアプローチを現在調査中です。
楽観的なっていうのはまた
オプティミスティックという
英単語でしたね。
楽観的って訳してますけど。
ちょっと今何も想像できなかった。
続いて
プリレンダリングですね。
ページ遷移時間を
改善するアプローチの一つに
ユーザーが操作する可能性のある
コンテンツをプリレンダリングする方法があります。
例えばユーザーがリンクの上に
マウスを置くとアプリケーションはそのページを
ネッシに追い込み始めるかもしれません。
サーバーコンポーネンツを使用する
アプリケーションでプリレンダリングを
すぐにサポートする方法については現在調査中です。
すごいな。
本当にいろんな方面で
考慮に入れてるっていうところですね。
最後
スタティックサイトジェネレーションですね。
静的サイトの生成ですけども。
クライアントコンポーネントと同様に
サーバーコンポーネントは
ランタイム、サーバー上ですね、と
ビルド時、ローカルまたはサーバー上ですけども
またはハイブリッドアプローチで
レンダリングすることができます。
サーバーコンポーネントと
静的サイトジェネレーションの
最適な
統合方法については現在も調査中です。
例えばサーバーコンポーネントの
出力ストリームをHTMLストリームに変換して
静的サイトが
明示的に設計されたロード状態の
OKを受けられるようにすることができるようになります。
というところでした。
本当にあれですね。
開発者のことをめちゃめちゃ考えて
今、React
サーバーコンポーネントの再設計を
見るという感じですね。
これでも本当にできたらかなり熱いなと思いますね。
そこに
Next.jsの恩恵もあって
そこが乗っかってくると
よりReact界というのが
また発達していくんだろうなという感はあります。
なるほどね。
ありがとうございます。
次の章に移ります。
ドローバックスですね。
ドローバックスってどういう意味なんだ?
初めて聞いた。欠点?
09:00
欠点っていう英単語でした。
欠点のところですね。
3つあります。
1つ。
新しい形式のコンポーネントを導入することは
学ぶべきことが増えることを意味します。
それもそう。
2つ目。
サーバーコンポーネントの制約が
全てのユーザー、特に
一つの環境で作業することに慣れているユーザーにとっては
直感的でない可能があります。
はいはい、まあそうだろうね。
特にフロントばっかりやってる人が
いきなりサーバーコンポーネントの概念から
入るのは結構確かに
ハードル高いんじゃないかなって
気はしなくはないですね。
もちろん多少、我々はノードJSを触ってはいるので
多少
バックエンドのことはわからなくはないですけど
ちょっと
考え方をシフトしなきゃいけないのかなっていう気はします。
はい、で3つ目。
この方法ではサーバークライアント
共有コンポーネントを区別されるのに
規約が必要であり、混乱したり不快に
感じたりする可能性があります。
この規約もちょっとね
リアクトチームが考えてくれたら
すごく嬉しいなと思いつつ
現場ではどういう風に使うかっていうのはやっぱり
我々で考えていかなきゃいけないので
より最初の設計で
時間を使ったりする可能性がありますし
コース見積もりするときも
ちゃんと時間を取らなきゃいけないな
っていう感じはありますね。
ただ
導入してあまりあるメリットは
ある気がするので
いきなりドーンとやりましょう
っていう勇気がいるかもしれないですけど
ちょっとずつ段階的に
導入できればなっていう気はします。
そんな言うほど
大きい欠点ではなかったなって感じは
しましたね。
続きまして
オルタネイティブですね。
代替っていう英単語ですけど
では続きはそこです。
代替ですけども
本提案に対する様々な代替案を
検討しましたと。
これは5点あります。
1つはクライアントオンリーレンダリングですね。
クライアントのみのレンダリング。
もちろん2点目ですね。
その逆サーバーのみのレンダリングですね。
サーバーオンリーレンダリング。
続いてサーバーサイドレンダリング。
次スタティックサイドジェネレーションで
最後AOTコンパイルですね。
この5つを一応代替案として検討していますと。
これらのアプローチは
いずれも本提案のメリットを実現するものであり
多くのアプリケーションが
これらのアプローチを取り入れることによって
なおメリットを享受できると考えていますと。
しかしどの手法も単独では
本提案が実現する開発者の使いやすさとか
ユーザーの使いやすさ、機能の組み合わせを
達成するには十分ではないよというふうに
言っていますね。
まあまあそうだろうという感じはありますので。
これがどうなるのかというのは
気になるところであります。
はい。
ただ確かこの提案続きがあるらしいので
その続き見てみたら
ちょっと違うかもしれないですけどね。
はい。では続いて
えー
アダプションストラテジーです。
で
アダプションストラテジー、アダプションってなんだっけ
えー採用か。
12:01
の戦略ですね。
じゃあ採用戦略のところです。
前述の通り、サーバーコンポーネンツを使用するには
アプリケーションのルーティングシステムとか
バンドルソフトとの統合が必須ですと。
で、コミュニティがこの仕組みを理解するために
私たちはまず一つまた複数のフレームワークに
サーバーコンポーネンツのサポートを追加することに
招待をやっています。
やっぱりフレームワークの話をしてますね。
で、それリアクトチームがいくつかピックアップした
フレームワークにサーバーコンポーネンツのサポートを
追加することを
お話をしてるみたいな話を
してると思ってます。はい。
で、これによって
開発者はサーバーコンポーネンツを簡単に試すことが
できるようになりますと。
また、ライブラリーの作者がどのようにサーバーコンポーネンツの
サポートをライブラリーに追加して
個々のアプリ開発者がどのように
アプリにサポートを追加するかのガイドとしても
やる予定ですと。はい。
ありがたい。そう、そこが重要。
結構大きい変更ですし、
サーバーコンポーネンツの本気で導入するのは
今までの僕らの
持っているJSフレームワークでの作り方に
結構抜本的な
改革が入るに近い感覚が
僕はあると思っているので、
やっぱりガイドが何か知らないと困るなという感じ
はありますね。
はい。で、続いてHow we
Teach thisですね。
どのように教えればいいのかというところですけど、
まずサーバーコンポーネンツというのは
実験的な機能であって、
まだアプリケーションが簡単に採用できる段階
でないことに注意してください。
サーバーコンポーネンツを安定した機能として
リリースする準備ができたら、
Reactのドキュメントを更新し、サンプルを提供し、
開発者が上記の新しい規約に従えるように
イントルールも
リリースする予定です。やったね。
また開発者がサーバーコンポーネンツを
簡単に試すことができるように
一つまたは複数のフレームワークと
関係する予定です。
ありがたい。ちゃんと
リントがあるんですね。
はいはいはい。
どんどんいきますよ。続いて
クレジット&プライオリー
パーアートかな。プライオリーじゃないな。
これなんだ。
読めない。ピリオアって読むのかな。
プライオアートかな。
はい。
略すとクレジット先行技術。先行技術って
略になるのか。アートってそうなんだ。
へー。
はい。いきます。
サーバーコンポーネンツって複数のソースから
アイディアを合成するものですと
3つあります。1つは
従来のサーバーレンダリング
PHPとかレールとか
本当にバックエンド系のビルですね。
従来のサーバーレンダリングと
特にFacebookの
古いウェブアーキテクチャでは
PHPで書かれたサーバーコンポーネントが
ネイティブのDOMやクライアント要素
クライアントコンポーネントですね。
with Reactって書いてますけど
をレンダリングすることができるようになります。
10代のものでも一応
できるようになるってことですね。
従来の
サーバーサイドのフレームワークとかと
サーバーコンポーネンツがうまいこと
連携できてるようになったら
それはまた面白いけど
なんか責務の分け方難しいなっていう
気もしますけどね。
どこまでをバックエンドのフレームワークに渡して
どこまでをサーバーコンポーネンツでやるのかっていう
線引きとか区分けを
15:01
しっかりしないと
線引きが曖昧になってぐじゃぐじゃ
ってなりそうな気もしますけど
その辺は多分リントルとか出してくれたり
するのかもしれないです。
2つ目ですね。
2つ目はリレーの
データ駆動型の
リレーのデータ駆動型の
依存関係によって
サーバーどのクライアントコンポーネンツを
使用するかを動的に選択することができます。
はいはいはい。
うーん
しか言いようがないな。
ソースコードの具体的なものを見ないようです。
本当に?っていうのはちょっと僕今
疑問には思ってるんですけど。
はい。
3つ目はグラフQLですね。
グラフQLはクライアントサーバー
クライアントサイドのアプリケーションで
データをロードする際に複数の
ラウンドトリップを回避するためのアプローチの
一つを示すものです。
結構グラフQLにも注目をしている
って感じですね。
はい。まあまあ確かに
ラウンドトリップを回避するに
グラフQLを使うのが一つのアプソリューションとしては
正しいなとは思っておりますけどね。
うんうん。なるほどです。
グラフQLも結局
BFFとして動くことがやっぱり
多いので、まあサーバー側
じゃあサーバー側ですからね。
なるほどです。
はい。で、最後
コメントの方にちょっと行きますけど
名前がいっぱい出てくるですね。
まあいろんな開発者の人たちの
発想とかアイディア
っていうのを
入って、または共同でアイディアを
発展させましたと。
さらに
同じようにいろんな人たちの
サーバーコンポーネントの最初の製品統合
っていうのを今内部で
絶賛開発をしていて
設計について実質的なフィードバックを
提供してくれましたと。
また外部パートナーであるGoogleの
Auroraチームとか
Chromeですね。ChromeのAuroraチーム
Auroraチームっていう名前があるらしいですね。
の人たちと
バーセルチーム
からすごい貴重な意見をいただきましたよ
という風に言ってます。
Googleとバーセルのチームと今連携をして
設計もしてるってことですよね。
なるほどでした。
では続きまして
ラストの章ですね。
ラストはFAQです。
順次読んでいきますね。
1つ目
サーバーコンポーネントっていうのは
サーバーサイドレンダリングの
代わりになるものなんですかね。
対応するものですかと言ってますけど
答えはノーですと。
補完的なものにはなりますよと言ってますね。
サーバーサイドレンダリングってのは主に
クライアントコンポーネント非インタラクティブバージョンを
素早く表示するための技術ですと。
最初のHTMLがロードされた後
それらのクライアントコンポーネントを
ダウンロードしてパースして
実行するコストがまだまだ必要ではありますよと
言ってますので
あくまで補完関係だということですね。
続いて
GraphQLの
もう1個コメントありましたね。
サーバーサイドレンダリングの
置き換えなのかという質問なんですけど
18:00
サーバーコンポーネンツと
SSRを組み合わせて
サーバーコンポーネンツが最初にレンダリングし
クライアントコンポーネンツが1点目
レンダリングをしてハイドレートされている間に
高速に非インタラクティブな
表示を行うことができるようになりますと。
このように組み合わせると
高速な起動が得られるだけでなく
クライアントでダウンロードする必要のあるJSの量を
劇的に減らすこともできますよと。
うまいこと組み合わせれば
よりコントローラブルに
アプリケーションの
レンダリングをすることができるという感じですね。
続いて
グラフQLにとって変わるものですか?
グラフQLのリプレイス
するものですか?というと
これも答えはノーですと。
グラフQLは言語の境界を超えて
過端然なクエリをサポートし
アプリケーションがフェッチ不足やオーバーを減らして
ラウンドトリップを減らすためののに役立つ
他の機能の中で
ワークポイントを構築するための
一つのアプローチですと。
これに対してサーバーコンポーネントというのは
ユーザーインターフェースの構築に
重点を置いていますよと言っていますね。
あくまで側の方に重点を置いた
サーバー側の処理だと言っていますね。
はい。
続いて
えー
みんなリプレイスの質問が多いですね。
アポロやリレイなど
リアクト用のグラフQLクライアントを置き換えるものでしょうか?
という質問が来ていますけど、これもノーですね。
前の質問で述べたように
グラフQLというのはAPIエンドポイントを
構築するために設計されていますと。
そのためグラフQLは
クライアントコンポーネントのデータをロードするための
多くの素晴らしいアプローチの一つで
あり続けるでしょうと。
さらに開発者はサーバーコンポーネントのデータを
ロードするためにグラフQLを使用することが
有用であるかもしれません。
例えば社内
これ多分フェイスブック社内かな。
サーバーコンポーネント組み合わせてリレイと
グラフQLを使用しているという風に今言ってますね。
実際に導入実施して
やっているという感じですね。
これはいい話。
続いての質問が
ちょっと長いな。
これはJavaScriptにコンパイラがないことを
回避しているだけなのでしょうかという質問ですね。
これも答えは
同です。
静的なコンパイラというのはいくつかの点では
役に立ちますけど、現実の多くのアプリケーションでは
ユーザー固有のオプションだったり
ABテストだったり
機能フラグだったり静的な最適化では
限界に達してしまうような動的な分岐が
たくさんあることが現在わかっています。
これについて別の
記事がありますね。
アボイディング・ザ・アブストラクションタックス
というのがあるのでその辺も見てください。
という感じです。
続いて
サービスワーカーで
キャッシュしているのですがそれでも必要ですかという風に
言ってます。
それについての答えは
As always
と言ってますね。
既存のソリューションが
うまく機能しているようになれば他のものに変更する
理由は別にないですよと言ってます。
モチベーションの章が
あるんですけどそこの辺も参照してもらうと
いいかもしれないですけど
これらの課題のいずれかがあなたに当てはまるかどうかを
判断してくださいと言ってます。
なるほどですね。
21:03
続いて
そもそもこのサーバーコンポーネントで使わなきゃならないんでしょうか
という質問ですね。
確かにそれは面白い質問だ。
既存のクライアントサイドのアプリを
持ちの場合はその全てをクライアントコンポーネント
ツリーと考えることが一応できます。
それが結構であれば素晴らしいことですし。
サーバーコンポーネントは
リアクトを拡張して他のシナリオを
サポートするものであってクライアントコンポーネントの
代わりとか代替になるものではないですよと
言ってます。
なるほどですね。
続いて
我々のアプリケーションがFacebookスケールである
場合にのみ関係するのでしょうか
スケールが大きいのでしょうかという話ですけども
これもノーだと言ってます。
前日の言ったとおり
モチベーションのセクションがあるんですけど
そのモチベーションのセクションを述べたように
サーバーコンポーネントっていうのはリアクト開発者が
直面する多くの課題に対応するために
設計されていますと
新しいアプリを書く場合APIサーバーを
立ち上げることなく
ファイルシステムやデータベースに直接アクセス
できます。
すでにアプリを持っている場合はAPIでデータを
公開しなくてもより柔軟に全ての
データにアクセスできるようになりますよと言ってますね。
そこは本気で大きいメリットだと思いますね。
クライアント側からファイルシステムまで
しっかりアクセスできるのは結構大きいなと思います。
ただデータベースにも直接アクセスできる
っていうのがやはり
セキュリティリスクのところが僕はすごい懸念はしてますけど
そこの辺がちゃんとサーバー側の処理だと
いうところでブロックができるんであれば
まだまだって感じですけど
そこをFacebookジムは懸念
しないはずがないはずなのと
信じてます。
続きまして
続いてはですね
ちょっとまたバッケンの側の話が
出てくると思うんですけど
フロントエンドのために
PHPとかJSPとか
Whateverとかを再発明していませんかと
言ってます。
再発明かどうかというところですけど
アプリケーション開発の歴史
っていうのは新クライアントと
新規クライアントの間で振り子を打つような連続でしたと
しかし現実にはどのアプリケーションにも
非インタラクティブで
即時のデータ整合性を
必要としない性的な部分と
インタラクティブ性と
即時の応答性を必要とする動的な部分
っていうのがありますと
純粋なサーバーレンダリングと
純粋なクライアントレンダリングはどちらも
全ての状況にとって理想的ではない
というふうに言ってますと
サーバーコンポーネントを
既存のクライアントコンポーネントと組み合わせることで
開発者は最も合理的なアプローチを使用して
アプリケーションの確保を求することができますよ
と言ってます。
要は再発明してるわけではないよと言ってますね。
新しいソリューションだと言ってます。
続いて
今すぐ自分のアプリでも使えますか?
っていう質問ですけど
これはもう読んだことある通りですけど
現状と今後の展開については
採用戦略のセクションをご覧くださいと
言ってます。
続いて
今Facebookの本番環境に導入されてますか?
というふうに聞いてますね。
これが突っ込んだ質問だな。
答えですけど
24:01
単一ページでの実験をすでに実施していて
有望な結果が得られています。
すでにプロダクトコードのサイズが約30%
削減されているという実績もあります。
サーバーコンポーネントで設計されたアプリでは
当初はもっと
節約できると期待しています。
と言ってますね。
なので全部導入されてるわけじゃないけど
一部単一ページでのみ
実験が入っているので入っている可能性があるな
というところですね。
続いて
これはNext.jsに特有のものですか?
という質問ですね。
これもNOだと。
我々はNext.jsで提携をしており
最初の統合をすでに構築しています。
しかしサーバーコンポーネントは
最初からあらゆるクレームワークで
使用できるように今設計している途中ですし
カスタマーアプリケーションの
セットアップに統合することも可能だと考えている。
サーバーコンポーネントは
ルーター、バンドル、サーバーとクライアントの連携など
その範囲を考慮すると
高品質な初期統合によって
他の開発者にセットアップを実装することが
できましたと言っています。
やっぱり気になるのは
Next.jsのサーバーサイオレンダリング周りのところとの
統合ですからね。
線引きであってどういうふうに連携するのかな
というところは注目かなと思います。
後ほどいろんなルールだったりリントだったりも
出ると言っていますので
もうちょっとアップデートを期待したいなという感じですね。
採用戦略の経緯は
特別な章が付いてあるのでそこを見てください。
質問まじめっちゃあるな。
あと3分で終わる気が
死ねー。
ちょっと舐めてたな。
あと3分で終わらないので
行けるところまで行きます。
続いての質問ですけど
カスタマープロトコルの代わりに
HTMLを使用するのはどうでしょうか
というふうな質問ですね。
最初のレンダリングに
Streaming HTMLを使用したいのですが
カスタマープロトコルによって
カスタマープロトコルのコンポーネントプロップ
を転送してツリーを調整して
クライアント状態だけでなく
DOMのフォーカスもしくはスクロールもしくは状態
も吹き飛ばされないようにすることができるようになりますよ
と言っていますね。
なのでHTMLを使用するというのが
使用したいんですけど
解決できる問題は違うなという
話をしてそうですね。
続いて
静的生成
スタティックジェネレーションのほうが
ベターじゃないのというような質問ですね。
スタティックジェネレーションというのは
いくつかのユースケースには最適であるというのは
認めます。
そのためにビルド時にサーバーコンポーネントを
実行することができますので
そこに含められますよというふうにも言っていますね。
サーバー側で
処理をやることができるのであれば
クライアントで今ゴニョゴニョやっている
重い処理というのは全部サーバー側に押し付けられるので
メリットが大きいのでスタティックジェネレーションのほうが
いいのかという質問はちょっと
微妙だなと思いましたね。
続いて
デバッグの話はどうなっているんですかというところですね。
これ結構大事だな。
最初はノードでAPIをデバッグするのと同じですけれども
サーバーコンポーネントを
Dev用のワーカーに入れてクライアント用と並べて
デバッグできるようにすることを
27:01
今現在研究中でありますと。
新しい考え方というのは
オープンな研究分野というのがあるので
その記事がありますね。
オープンエネスオブリサーチというのがあるので
そこをご覧くださいと言っていました。
続いて
サーバーコンポーネントとクライアントコンポーネントの
どのように行われるのか、まだ制限はありますか
という話をしていますけれども
こちらについても既に記事2つ
記事でセクションで分かれているんですけど
Capabilities and Constraints of
Server and Client Components
というセクションと
Sharing Code Between Server and Client
というセクションがあるので
そこを見てくださいと言っています。
続いて
React Nativeにはどのような意味があるのでしょうかと
言っていましたね。
React Nativeの初期の概念実証を
検討しましたけど
現在は優先順位をつけていませんと
残念ながらというところですね。
長期的にはサーバーコンポーネントは
React Nativeや他のレンダラーでサポートされる可能性はありますよ
と言っていますね。
検討は一応入っているけど
優先度は低いんだろうなと
そもそもつけていないと言っていますからね。
続いて
データベースはコンポーネントから直接読み込まなければならないのですか
という質問ですね。
データベースに直接アクセスできる
ようなことを書いているので
いけるのかという話ですけど
これに関してはノーだと言っていますね。
立ち上げ当初は便利かもしれませんけども
目標というのは
スケールアップやスケールダウンを可能にし
アプリを書き換えることなく
データベースへの直接アクセスやマイクロサービスなどの
アプローチを自由に聞きできるようにすることですと
またクエリのバッジ処理とか
認証レイヤーを提供するJavaScriptの
抽象化機能というのを構築することも可能です
と言っていますね。
なので
コンポーネントから直接読み込むなきゃならないのか
という質問に対してはノーだと言っていますね。
もちろん
立ち上げというのは
アプリケーションのスターティングアップの話かな
にはもちろん便利かもしれないですけどね。
あとはソフトウェアにぶち込めばいいので。
はい。
30分経ったのでラストですね。
サーバーコンポーネンツ用に
独自データレイヤーを書くことはできますか
という質問ですね。
これに関してAPIは安定した時点で
ドキュメント化される予定ですが
基礎となるライブラリのデータ要求をどのように
重複排除し
キャッシュするかをリアクトに指示する必要は
やっぱり出てきますよというふうに言っていますね。
はい。
回答としてイエスどうなのかちょっとわからなかった感じですけど。
はい。というところでちょっとすいませんけど
時間が過ぎてしまったので
一旦今日の朝活動は以上にしたいと思います。
続きまたこのFAQやって
次は何のドキュメントを読むかちょっと悩ましいんですけど
また何か読んでいこうと思います。
明日は一応そのレスポンスフォーマーとは何ですか
という質問の回答からやっていきたいと思いますので
またゆるゆると聞いていただけたらありがたいなと思います。
では今日も一日頑張っていきましょう。
お疲れ様です。ありがとうございました。
