00:05
5月27日、金曜日ですね、地獄は朝9時を回りました。
今日の東京は、入りに行くの雨ですね。
はい、おはようございます。ゆめみの桑原ですが、皆さんいかがお過ごしでしょうか。
本日も朝活を始めていきたいなと思っております。
はい、タイトルある通り、本日もNext.jsの
Layout RFCの数字を読んでいきたいなと思っております。
お、Kさんですね。お参加いただいてありがとうございます。
タイトルある通りですけど、Layout RFCという
Next.jsのブログをただただ読むだけの回って感じですね。
で、昨日がどこまで行ったかな。
昨日一応読んでいってて、
一旦そうですね、How Routing Currently Worksで現在のルーティングがどのように動いているかというのと、
新機能のとりあえずアップホルダーを導入するところまで確か読んだような記憶がありますね。
なので、続いてDefiniting Rootsのところ。
これも読んだ気がするな。はい、ルーティングの定義のところを読んでいたので、
続いてルートセグメントかな。ちょっともしかしたら昨日と被ってるかもしれないですけどね。
はい、じゃあルートセグメントの話を今日から入っていこうかなと思います。
では、お決まりのDeepL3に大変にお世話になりつつ読んでいきたいと思いますが、
では行きますね。サブツリー内の各フォルダーというのはルートセグメントを表しますと。
その各フォルダーというのはアップホルダーができて、その下に例えばダッシュボールとか、
その前にその下にセッティングするとかディレクトリをどんどん掘っていくと、
その各セグメントがルートとして一致すると。
URLパスの対応するセグメントが内部的にマップされますよと言ってますね。
なので階層を掘るとアップのところがいわゆるスラッシュですね、ルートセグメントになって、
そこの下にダッシュボードって例えばディレクトリを切るとスラッシュダッシュボードでアクセスできるようになると。
その下に掘るとまた同じようにURLの後ろにセグメントが入るよってことを言ってますね。
これは一般的なURLパスと一緒なのかなと思っていたりはします。
続いてレイアウト&クリエイティングUIの話ですね。
これは新しい機能としてレイアウト.jsっていうファイルで定義をしなきゃいけないよっていうのが紹介になると思いますけども。
これまで使ってきたアプリケーションのルートを定義するためには、いわゆるフォルダをずっと今まで説明してきた通りですね。
フォルダ単位でそのアプリケーションのルートっていうのを定義してきましたと。
しかしですけど空のフォルダだけだと別に何も動作はしませんよと言っていて、
ここでは新しいフォルダ規約を使ってルートにレンダリングされるUIを定義する方法を説明していきますと。
03:06
レイアウトですね。
レイアウトはサブツリー内のルートセグメント間で共有されるUIのことですと。
レイアウトはURLパスに影響しなくて、ユーザーが同じレイアウトを共有するセグメント間を移動したとしても再レンダリングはされませんよと。
ただリアクトの状態自体は保っていますよというのを言ってますね。
そこは担保してますよということでした。
続いてレイアウトっていうのはデフォルトでレイアウト.jsファイルっていうのをリアクトコンポーネントとしてエクスポートすることで定義できますと言ってます。
これはもう名前もしっかり決まってるっぽいですね。
新しいルーティングを使いたい場合はレイアウト.jsっていうファイルを作ってリアクトのコンポーネントとしてエクスポートしてくださいと。
このコンポーネントにはいわゆるチルドレネのプロプスも指定できますよと。
そのチルドレネプロプスにはレイアウトを包むようなセグメントとかコンテンツを入力してくださいっていうことでしたね。
次にレイアウトの話なんですけどレイアウトには一応二つnext.jsが定義があってですね。
一つはルートレイアウトですね。
これはアプリケーション全体に関わるようなルートのレイアウトですね。
もう一つがレギュラーレイアウトと言ってこれは特定のセグメントに適用されるレイアウトですね。
さっきのようにApp Directoryの下にセグメントって言えちゃいない。
ダッシュボードかっていうディレクトリを切ったらそのダッシュボードの中にレイアウト.jsファイルを作ると。
そうするとその中だけに適用されるレイアウトっていうのが定義できるっていうことですね。
もちろんこれはレイアウトを入れ子にしたりnext.jsレイアウトをすることもできますよって言ってました。
今言った二つの説明が若干入っててルートレイアウトは文字通りAppの下ですね。
App Directoryの直下に置くレイアウト.jsファイルっていうことですね。
ここに置くことでアプリケーション全体に適用できますよと言ってます。
ちょっと注意書きがあってですね。
注意としてはルートレイアウトっていうのはすべてのルートに適用されるためカスタムアップって言われるもの。
いわゆる現在のunderbar app.jsとかカスタムドキュメントですね。
underbar document.jsファイルの必要性にとって変わられますよって言ってますね。
こっちに置き換えられるって言ってます。
ルートレイアウトを使用して最初のドキュメントですね。
ドキュメントシェルか。
HTMLタグとかボディタグみたいなHTML全体を包むシェルみたいなものをカスタマイズすることができるようになると。
ルートレイアウトおよび他のレイアウト内部でデータ取得メソッドもその中で使うことができますよと。
ゲートしたデータ取得メソッドって言ってるのはいわゆるGetStaticPropsとかで横サーバサイドプロプスみたいなお話じゃないかなと思ったりしてます。
今のがルートレイアウトで。
続いてレギュラーレイアウトですね。
レギュラーレイアウトはさっきも言った通り、
06:02
Appの下に何かディレクトリを掘ってそのディレクトリの中にレイアウト.jsを置いておいて、
それがそのセグメントだけにしか適用されないと。
そのセグメントの中にさらにフォルダを掘ったらその下の階層にまで一応影響はしますよってのを言ってますね。
スコープを絞ったレイアウトを作る場合はそのレギュラーレイアウトっていう呼び方をするそうですね。
ネスティングレイアウトです。
ネスティングレイアウトっていうのはレイアウトだったらデフォルトでネストしますよって言ってまして、
これちょっとなかなかな。
画像とか画面共有できれば一番いいんですけど。
できるのかな。
誰かがTwitterスペースで画面共有できるみたいなことを言ってたような気がするんですけど、
ここがちょっと見当たらないんだよな。
まあいいや。
ちょっと口頭になっちゃいますけど。
ネスティングレイアウトの話ですね。
例えば、
アップの下にレイアウト.jsファイルを作って、その下にダッシュボードを作って、
そのダッシュボードディレクトリの下にさらにアナリティクスとかセッティングスみたいなディレクトリを切っていたとしましょう。
その場合はルートレイアウト、アップの下のレイアウト.jsはダッシュボードレイアウトにも適用され、
ダッシュボードディレクトリの下の全てのセグメントにも適用されるという話でした。
それがネストの話ですよということですね。
続いてページの話ですね。
今までレイアウトの話をしたので次ページの話ですね。
ページなんですけど、今のネクスト.jsは、
失礼。
ページズディレクトリの下に置いてたと思いますけど、
各ディレクトリの下にpage.jsというファイルを作ってくださいというふうに言っています。
for example appですけど、これも一緒ですね。
さっき言ったようなアップの下のレイアウトはありますけど、
その下にダッシュボードってディレクトリを切った場合は、
そのダッシュボードディレクトリをページとして見たい場合はpage.jsを作る。
その下にさらにディレクトリを切ってセグメントを用意した場合は、
そのセグメントの下にもpage.jsファイルを作ってくださいねと言っています。
はい。
レイアウト自体もそのまま、
そのセグメントのルールが適用されるのでそのままですね。
続いて、
you can create a page.js file directly はいはい、そうですよね。
注意事項が確かあったと思うんですけど、
注意事項はですね、
そのルートが有効であるためには、
その下の方のマッタの方のセグメントにページがある必要があると。
その場合は、それがない場合ですね。
っていうのは基本ルートは404になります。
例えばさっき言ったアップの下にセグメントですね、
09:01
ダッシュボードってディレクトリを切ってて、
そのダッシュボードページにアクセスするには、
スラッシュのダッシュボードにアクセスすればいいと思うんですけど、
そのダッシュボードにページとして表示させたい場合は、
page.jsを作ってくださいと。
だからディレクトリ切ってあっても、
page.jsがなければルーティングされないよって言ってます。
404になるって言ってましたので、
ちゃんとページとして表示したい場合は、
page.jsっていうのを作ってくださいと。
で、page.jsファイルっていうのはデフォルトで、
こちらもリアクトコンポーネントとしてエクスポートしてくださいと。
で、名前はもうpage.までは確定で、
その後は拡張子としてjsとjsx、tsとtsxの4パターンいけますよって言ってました。
で、作ったはいいんですけど、
page.jsファイル例えば作って、
それがリアクトコンポーネントとしてエクスポートしてない場合は、
Nextはエラーを投げてくれるそうですね。
というような設定だそうです。
これがですね、よしよしというか好み分かれると思いますね。
わざわざpage.js作るとか、
layout.js作らなきゃいけないんで、
しかもその名前も固定ですって、
それに縛られるっていうのに、
違和感というかモヤモヤがあるなっていう風な意見を、
僕の社内で聞きましたね。
なるほどって思いました。
では続いてレイアウトと、
ページのビヘイビア振る舞いの話ですね。
入っていこうかなと思いますが。
軽くおさらいですと、
page.jsコンポーネントっていうのは、
いわゆるpage.jsのデフォルトのエクスポートですと、
さらにlayout.jsコンポーネントは、
layout.jsのデフォルトのエクスポートです。
で、layout.jsコンポーネントっていうのは、
チルドレンのプロプスを受け入れなければなりません、
という風に言ってました。
ここまでは今までの、
nextのレイアウトRFCのお話のおさらいですね。
で、そこから続いていくと、
親レイアウトがページに到達するまで、
最も近い子供のレイアウトを選択する、
レイアウトツリーとして可視化する方が、
実は簡単かもしれませんねっていう風に言ってました。
ほう、なんだなんだ。
で、例えば、ベーシックエグサンプルなんですけど、
この辺からソースコードが出てくるんで、
非常に見づらい気がしているんですけど、
ご容赦いただければと思ったりはします。
大変に申し訳ないですが。
で、最初にルートレイアウトですね。
appの下のlayout.jsのファイルです。
ソースコード的には、よくあるエクスポートデフォルトで、
関数定義、ファンクションで定義して、
ルートレイアウトという名前で定義しています。
引数にchildrenという名前で受け取って、
returnですね、return.jsxになっています。
これはルートのレイアウトなので、
htmlとbodyタグから書いてますね。
htmlがあってbodyタグがあって、
その中にheaderというコンポーネントと
childrenとfooterというコンポーネントが配置されています、
みたいな感じですね。
その下ですね、その下はregular layoutの例ですね。
12:01
これはappの下にdashboardというディレクトリキッドやって、
その下にlayout.jsというのを作ってあると。
これも同じようにエクスポートデフォルトで
関数コンポーネントとして定義しています。
名前はdashboard.layoutという名前になって、
同じようにchildrenを引数に受け取ります。
return.jsxで、
あれですね、やばい、名前忘れた。
空のタグみたいなやつ。
リアクトでよく使うやつ。
名前忘れてしまったな。
あれを置いて、その下にdashboard.sidebarみたいなやつですね。
今回は特別なsidebarというコンポーネントを作った前提でやるらしいですね。
さらにchildrenというのを置いています。
最後にpageコンポーネントとして、
適当なpage.jsを作って、
こちらもエクスポートデフォルトで、
いわゆる関数コンポーネント的に定義をします。
こっちは別にchildrenというのを受け取らなくてよいよというか、
この子自体が子供みたいなもんですからね。
return.jsxのメインタグとかを置いたり、
メインコンテンツだと置いてくださいねというような作り方で作ってくださいということでした。
それをすると最終的にビルドされて
吐き出されるものは、
root layoutというコンポーネントが作られるらしいですね。
あ、そうなの。
root layoutという名前のコンポーネントだからですね。
作られて、ヘッダーコンポーネントが中に入って、
ダッシュボードレイアウトが作成できて、
ダッシュボードレイアウトの中に
ダッシュボードのページができるので、
ダッシュボードサイドバーとかアナリクスページとかみたいなのが出てくると。
いわゆるさっきのネストシア回送のものがどんどんHTMLとして
一つのものにガチャンとなってますよというような見方ですね。
そういうヒエラルキーがちゃんと作られてますよというお話でした。
これはすいません。
ソースコードを見たら一目瞭然なので見てくださいって感じですね。
続いてリアクトサーバーコンポーネントのお話が来るそうですね。
結局リアクトのサーバーコンポーネントを僕はあんまり追ってないので、
しっかりちょっとここで勉強し直したい感はありますが。
最初に注意事項から入ってますね。
リアクトサーバーコンポーネントに慣れていない場合は、
このセクションを読む前にリアクトサーバーコンポーネントのRFCを読むことをお勧めしますと、
なるほど、このドキュメントをお前はまだ読む段階にいないぞと怒られましたね。
リアクトサーバーコンポーネントのRFCドキュメントを見に行くとですね、
これはリポジトリの中のドキュメントなんですけど、
めっちゃ長い。
もうすごく長い。
いやーどうしようかな。
長いのでこれ読んでいったらキリないですので、
ただ一方で読まないと、
多分これサーバーコンポーネント知ってますよねっていう前提で書かれてると思うんで、
一旦飛ばします。
はい、ちょっと僕が不勉強で申し訳ないです。
もし時間あったらここに帰っていきたいと思いますし、
なかったら明日リアクトサーバーコンポーネント勉強し直してから読みたいと思いますね。
15:02
飛ばさせていただいてデータフェッチングの話に移ろうかなと思いますね。
データフェッチングですけども、
Layout.jsのファイル内でNext.jsのデータ取得メソッドを利用することができますよと。
それがたぶんgetServerAssignedPropsとかgetStaticPropsみたいなやつだと思います。
Layoutっていうのは入れ込みにすることができるので、
ルードの複数のセグメントでデータを取得することもできます。
各セグメントの方のLayout.jsでももちろんデータを取得することができますよと言ってますね。
これはPagesDirectoryではデータ取得メソッドがページレベルに限られていたっていう、
限定されていたとはちょっと異なりますよっていう振る舞いになりますと。
なるほどですね。
具体例の話がちょっと入ってきますね。
1つ目がデータフェッチングinLayoutsなので、
Layoutの中でのデータフェッチングの話をしています。
先ほど言ってましたLayout.jsの中ではgetStaticPropsとgetServerAssignedPropsですね。
どちらか使うことができますよと言ってますね。
例えばgetStaticPropsを使う例ですね。
ブログがあってその中のLayout.jsで呼ぶ場合ですね。
CMSからカテゴリとかのデータを取ってくる場合のソースコードの例が出ますけど、
AppDirectoryの下にブログっていうディレクトリが切ってあって、
その下にLayout.jsが作られているとしましょうと。
その場合ExportでAsyncFunctionの関数の定義がしてあって、
getStaticPropsが定義してありますと。
ここでgetCategoriesFromCMSみたいな適当なメソッドでAPIをコールして、
データをCategoriesという変数で受け取ってますと。
リターンするときにPropsというキーを付けてCategoriesをオブジェクトとして返してますと。
これがgetStaticPropsの定義ですね。
Layoutのほうです。
Layout本体のほうでExport Defaultの関数コンポーネントとしてファンクション定義してます。
ブログLayoutという名前で引数にさっきほどプロップスとしてリターンしたCategoriesというものと
あとチルドで2つを受け取って、
あとはリターンの中でガチャガチャっというふうにそのデータを使えますよと言ってますね。
これいわゆる今までのNext.jsのgetStaticPropsの使い方が
Layoutでそのまんまできますよという話ですね。
続いてMultipleDataFetchingMethods in a Rootというところですね。
Rootの中でMultipleのDataFetchingのメソッドが使えますみたいな話ですね。
これは何かというと
さっきと同様にまたルートの複数のセグメントでもデータをフェッチすることができますというですね。
それぞれのセグメントの話です。
例えばデータをフェッチするLayoutというのはそれ自身のデータをフェッチするページをラップすることもできます。
さっきのブログの例ですね。
ではその単一の投稿ページでgetStaticPropsとgetStaticPathsを使用して
18:04
CMSからデータを取得することもできますよって言ってましたね。
さっきのソースコードがちょっと拡張になって
さっきはブログのディレクトリの下にレイアウトとかページを作ってたんですけど
今回はAppDirectoryの下にブログディレクトリ切ってあって
よく使うスラグってやつですね。
カギ括弧スラグっていうディレクトリの中のページでJSっていうファイルで今回は定義してるそうですね。
その定義が同じようにExportAsyncのファンクションのgetStaticPathsという関数ですね。
ここでアウェイトしてまずポストを取ってくるとかですね。
getPosts slugs from CMSというのでポストデータを1回取ってきますと。
で、リターンでオブジェクトでリターンします。
で、キー名にPathsっていうキーをセットしてあって
さっき受け取ったPostsっていう変数をマップしてますね。
で、配列を作って返してます。
で、その時にリターンする時の、これは配列で返すんですけど
配列の中身はオブジェクト配列になってて
そのオブジェクトの中身がparamsっていうキー名で
値がそのスラグの中のPosts slugを1個1個定義してるって感じですね。
っていうオブジェクトになってますと。
で、それをリターンします。
で、getStaticPathsをリターンしてるので受け取るのはgetStaticPropsのほうですね。
で、getStaticPropsは同じようにエクスポートのasyncファンクション関数名で
さっきリターンした時のキーの名前、paramsで受け取りますと。
で、その受け取ったparamsのスラグを使って
今度はgetPosts from CMSでCMSから今度はポストデータの
詳細が1個1個のやつですね。
のを取りに行ってます。
で、リターンでまたPropsでポストっていう今受け取ったものを返してあげて
本来のページのところで受け取るって感じですね。
こういうふうに使うこともできますと言ってますね。
ページのほうでそれをラップして使うこともできますと。
で、なんかコメントがあるのでコメントも一緒に読んでいきたいですが。
AppのブログのLayered.jsとAppのブログのスラグのPage.jsっていうのは
共にgetStaticPropsを使っているので
Next.jsっていうのは
スラッシュブログスラッシュスラグ
っていうのとルート全体をReactサーバーコンポーネンスとして
ビルド時に静的に生成することができますよと。
Reactサーバーコンポーネンスっていうのは
クライアントサイドのJavaScriptを減らして
高速なハイドレーションを実現できますっていうようなものですと。
で、静的に生成されたルートっていうのは
クライアントナビゲーションがキャッシュ
キャッシュっていうのはサーバーコンポーネントのデータのことをキャッシュするって言ってますね。
そのキャッシュを再利用して再計算作業を行うようにするため
21:00
これを改善してサーバーコンポーネントのスナップショットっていうのをレンダリングしているため
CPU時間の短縮につながってますっていうのを言ってます。
はぁはぁなるほどね。スナップショットをレンダリングしてるんですね。
だからまあ再計算もしないしそのままただ描画するだけだよ。
だから早いよっていう風に言ってますね。
なるほどでした。
んーその辺もヨシナに作ってやってくれるってことですね。
ほーい。
続いてBehaviour and Priorityなので
振る舞いと優先度っていうお話かな。
だと思いますのでそこに行きましょう。
あと7分ギリギリ足らない気がするな。
行けるとこまで行きます。
はい。ネクストJSのデータ取得メソッド
さっきから出ているゲットサーバーサイドプロプスと
ゲットスタティックプロプスの2つですけど
っていうのはそのAppフォルダー内のサーバーコンポーネンツでのみ使用可能です。
ん?なんだ?さっきと言ってることがちょっと違うぞ。
Appフォルダー内のサーバーコンポーネンツでのみ使用可能
あーサーバーコンポーネンツであれば使えるってことか。
だから別に矛盾はしないですね。失礼しました。
1つのルートにまたがるセグメント内の異なるデータ取得メソッドは
互いに影響しあいますよって言ってますね。
はぁはぁはぁ。
で、とあるセグメントの中で
ゲットサーバーサイドプロプスを使ってみたとしましょう。
そうすると他のセグメントでは
ゲットスタティックプロプスを使用した場合にも
それが影響出ますよって言ってます。
他のセグメントで性的な方のデータ取得メソッドを使うと影響が出る。
で、リクエストっていうのはすでにサーバーサイドプロプスですね。
ゲットサーバーサイドプロプスのセグメントのために
サーバーに行く必要があるので
サーバーっていうのは全てのゲットスタティックプロプスメソッド
セグメントもレンダリングをしちゃいます。
はいはい。
で、ビルド時に取得したプロプスを再利用するので
データは性的なままです。
キャッシュするからね。
で、レンダリングはリクエストごとにオンデマンドで行われて
次のビルド時に生成されるプロプスを使いますと言ってますね。
うーん、これどうしたらいいんだ?
で、またとあるセグメントでゲットスタティックプロプスを
withRevalidate
ISRか。
を使うと
他のセグメントでゲットスタティックプロプスwithRevalidateに影響を得ます。
ゲットスタティックプロプスを他でも使ったらそれ同士も影響します。
1つのルートで2つの有効化の設定がされている場合は
短い方の有効期間の方が優先されます。
有効期間って言ってるのはコールの短い時間の話をしてるのかな?
ISRだからそれの有効期間の話か。
っていうのがあった場合は短い方が優先されます。
注意として将来的にはルート内のデータ取得の流度を
24:01
完全に指定できるように最適化される可能性がありますけど
今のところまだできないよっていう話ですね。
ここはちょっとなんか気をつけないとバグにつながる気がするんで
もうちょっと追っていきたいし
今後の更新を待ってみたいですね。
互いにデータ取得のメソッドが影響しあったりするし
優先度が変わるっていうのであればここはちょっと気をつけたいですね。
っていうところまでしか今書いてなかったので次に行きます。
これはデータフェッチング&レンダリングwith Reactサーバーコンポーネンツっていうことですね。
データ取得とReactサーバーコンポーネンツのレンダリング関係の話をしてそうですね。
サーバーサイドのルーティングで
Reactサーバーコンポーネンツとかサスペンションとかストリーミングの組み合わせっていうのがあって
それらはNext.jsのデータフェッチとしてレンダリングにいくつかの資産を与えてますよと。
これがパラレルフェッチング&レンダリングなので並列とレンダリングの話ですね。
Next.jsではウォーターホールを最小化するためにデータ取得を並列に開始するようになりました。
サスペンスと組み合わせるとReactっていうのはリクエストを完了する前に
サーバーコンポーネントレンダリングをすぐに開始して
リクエストを解決するとその結果を取り込むことができるようになります。
これはReact 18の話ですね。
例えばデータの取得が順次行われる場合はルート台の各ネストされたセグメントでは
前のセグメントが完了するまでデータの取得を開始できません。
ブロックするの?
なるほど。
レンダリングがデータフェッチに依存している場合は
各セグメントはデータフェッチが完了した後にのみレンダリングできますと言ってますね。
ほー、なるほど。
意外とブロッキングするのかこれ。
それをパラレルにできるようになるのかな?
で、ウィズパラレルフェッチングっていうのがあるらしいですね。
今はブロッキングしちゃうような設計になっているけども
翻訳が追いついてこない。
しかしながら並列フェッチでは各セグメントが同時にデータのフェッチを開始することができますと。
並列フェッチっていうのを使えばいけるって言ってますけど
なんか特別オプションとかメソッドが書いてあるわけじゃないので
一応コンセプト概念としてそういうものが入れるつもりですよっていうのは言ってますね。
サスペンスではデータが完全に読み込まれてなくてもレンダリングもすぐに開始されますと。
もしデータが利用可能になる前に読み込まれた場合はサスペンションが発動されますと。
これはリアクト18のそのまんまの機能を使えますって言ってますね。
逆に言うとそれくらいリアクト18のサスペンスという機能はそれだけ影響が大きかったってことですね。
27:00
インパクトも確かにありましたしね。あれ便利だからな。
で、残り2分か。残り2分は…。
残り2分。あと1個だけセクションがあるのでそこまで行っちゃいましょうかね。
ラストかな。パーシャルフェッチング&レンダリングですね。
部分的なフェッチとレンダリングの話ですね。
セグメントディレクトリを掘っているのでその境内のルートセグメントがあって、
そういうルートセグメント間を移動するときですね。
っていうのはNext.jsっていうのはそのセグメントから下だけをフェッチングしてレンダリングしますと。
上は知らない。下の方のセグメントをデータフェッチングはしますと。
それ以上上については再取得するか再レンダリングは実は必要ないですよと。
つまりレイアウトを共有するページではユーザーが境内ページ間を移動してもレイアウトは維持されますし、
Next.jsはそのセグメントから下だけをフェッチしてレンダリングしますよと言ってますね。
あーなるほど。冒頭でも言ってたこの状態を保ちますけど、
スコープは切られてるしその中でデータフェッチもできますっていう話かな。
リアクトサーバーコンポーネントが特に有用ですと。
そうしないとナビゲーションごとにサーバー上でページの変更部分のみをレンダリングする代わりに
ページ全体をサーバー上で再レンダリングすることになります。
これによって転送されるデータ量と実行時間が削減されてパフォーマンスの向上にもつながります。
例えばユーザーがスラッシュアナリティクスページとスラッシュセッティングスページの間を移動したいとしましょうと。
その場合リアクトはページセグメントを再レンダリングしますけど
レイアウトは保持しますと。
回送内にあるセグメントだからアナリクスとセッティングスが同じ回送内のセグメントだとしたら
その親の方で定義しているレイアウト.jsというファイルがあって
それがもちろん2つ共有されますし、そこはすでに計算済みなので
そのレイアウトは保持しているから再計算は終わるということですね。
注意事項としてツリーの上位にあるデータを強制的に再取得することが可能になる予定です。
それも結局できるようにするんですね。
この方法について詳細は現在検討中でRCを更新する予定です。
ということでした。
ラストはコンクリジョンだけなのでここだけ読んで終わりにしたいと思います。
コンクリジョン、結論、まとめになる気がしますけど
結論、我々はNext.jsにおけるレイアウト、ルーティング、データ取得の未来に期待をしています。
RFCの次のパートではその辺も議論していきたいと思います。
インスタントローディングステートというのがあるらしくて、これはサーバーサイドのルーティングでは
ナビゲーションを完了する前にレンダリングとデータフェッチがサーバー上で行われます。
このためアプリケーションの応答性が悪くならないようにロード中のUIを表示することが重要になります。
私たちはインライン及びグローバルなローディングインジケーターとかスケルトンなど
30:02
インスタントローディング状態をフレームワークレベルでサポートすることを提案しています。
ありがたいね、これは本当にありがたいですね。
インスタントバックもしくはフォワードによるオフスクリーンスタッシングの話ですね。
リアクトというのは画面にレンダリングすることなくリアクトツリーとその状態を保存する
新しいオフスクリーンコンポーネントを追加することを計画しています。
このコンポーネントを活用することで一度訪れたルートを保持し
訪れる前にルートをプリレンダリングすることも可能になるはずです。
これらのルートへの後方及び前方へのナビゲーションは即座に行われて
以前に保存された状態が復元される必要がありますよね。
そうですね、なるほど、このオフスクリーンコンポーネントというのがその辺になってくれそうですね。
というのが次期リアクトのリリースに入りそうなので
そこをちょっと注目したいところですね。
並列ルートですね。一つのページに2つ以上のタブバーがある場合
iFrameに似たコンセプトで独立してナビゲートできる2つ以上の並列ネストされた
レイアウトを持つことが可能であるべきです。
続いてルートの遮断ですね。
時には他のページからルートを横取りすることができると便利です。
通常URLというのはUIの別の場所につながっていますけれども
このコンテキストでアクセスした場合はそうではない。
例えばインラインで展開して表示できるツイートとか
今ので終わりか。そういう場合があるので
UIというのはルートを横取りすることができた方がいいよねって話ですね。
ラスト。
ストリーミングと選択的なハイドレーションの話ですね。
サーバーセントリックなルーティングとリアクトサーバーコンポーネントと
サスペンションとストリーミングを組み合わせて
新しいルーティングパラダイムを可能にしてクライアントに送信するものをできるだけ減らして
作業を小さなチャンクに分割することでパフォーマンスを助ける方法についての詳細も共有します。
この辺全部GitHub Discussionsがあるのでそこにコメント残してくれたり
ぜひ会話に参加してくださいというようなお話でした。
以上にしたいと思いますが
思った以上にリアクトサーバーコンポーネントの話が重要そうでその辺理解しないと
途中なんだこれってなってしまったのでその辺理解していきたいと思いますが
明日までにそもそものサーバーコンポーネントのRFCを
僕は読み切ってくれるか自信ないので明日の朝ここで読む気がします。
金曜日ですが今日はこれで終了にしたいと思います。
33:04
じゃあラストですね。
皆さん仕事頑張りましょうって感じで終わりたいと思います。お疲れ様です。
