00:06
11月24日水曜日ですね。時刻は朝9時を回りました。 すみません、昨日おとといと体調を崩してましてですね。
朝活をやらなかったんですけど、今日からまたやっていきたいとおもいます。 まずちょっとまだ本調子ではないんですけどね。はい、おはようございます。
いめめのkeethことくわはらです。 じゃあ本日からまた朝活をやっていきたいと思います。
で、今日はですね、前々日と言った通り、公式ブログでレイアウトRFCのほうですね。
次期リリースであるRFCのいくつかを読んでて、その中の一つでレイアウトRFCとリアクトサーバーコンポーネンツのRFCをこの朝活でだいぶ前から実は読んでいたんですけど、それと
似たようなものを読もうかなと思ってたらちゃんと公式が出たので、温めて。 じゃあ早速入っていきたいと思います。NEXT-13ですね。
本記事、まあ公式ブログですけどが出てたのが10月の26日ですね。 今年の。なのでまぁまぁだいたい29日前ですよっていうことでした。
いくつかののがバーっとタイムラインに書かれているような感じですけど、 まずダイジェストですね。
NEXT.js Confで発表されたように、NEXT.jsの13、ステーブルですね、っていうのは制限のないダイナミックな世界を実現するための基礎を築いていますよと。
いくつかのものが出てまして、今回はApp Directoryですね。 まだベータ版ですけどApp Directoryというのがドラスティックに変わったようなところですね。
これはEasierであり、よりFasterであり、より 少ないクライアント.jsになるよということですね。
クライアント側の.jsがそれは少ないんだからそれは速いでしょうというのは、かつより少ないというのはすごくいい話ですね。
何か間があるよねって感じがしますよ。 ただそれより簡単にっていうところになっているので、本当に簡単なのかっていうのはちょっと難しい感じですね。
よりシンプルになったっていう言い方をしているんだったらあの 結構聞こえは良いですけど、よりEasier、簡単になったっていうとなんかいろんなものが考慮足りないんじゃないかな
っていう実際の使う現場の方での視点が足りてないのかなっていうふうに、 なんかちょっと邪推をしてしまうので、僕はですけど
Easierっていう言葉を使っていたので、僕は一歩離れた目線で見ようかなと思っています。
で、このApp Directoryの中にLayoutsというやつと、そのReact Server Componentsというやつと、ストリーミングですね。
というものがあります。まあまあ公式ブログなんですけど、これ一個一個別のリンクを貼られているんで、まあ別のリンクといってもこのブログ記事内の
ハッシュタグですねが貼られています。 続いて
ついにですね、Dext.js 13がWebpackから離れてTurboPackですね。 これはまだアルファ版ですけど、なんとUp to 700ですので700倍早くなったよというふうに言っています。
すごいですね、ついに700倍早くなると。まあWebpackがそんなに早くないっていうのは皆さんもご存知通りなんですけど、
そこから変えたらまさかの700倍早くなるっていうのは想像しなかったですね。
03:03
というところで、これそんなに早くなるんやっていうので気になりますね。 続いて、new-next-imageですね。
ちなみに700倍早くなったって言うんですけど、これは完全にWebpackを置き換えて、ラストベースのものですね。
のバンドラーに置き換えたってことだそうです。 そうすると700倍早くなったよってことですね。
続いてですけども、next-imageですね。 next-image-componentだそうです。
こちらはですね、ネイティブブラウザーのレイジーローディングで、より早く動くようになったよっていうことだそうですね。
続いて、newですね。またnewですけど、next-fontっていうものだそうです。これはベータ版ですけど新しく追加になったらしいですね。
この自動のセルフホスティックなフォントっていうのが、しかもゼロレイアウトシフトで導入できますよってことだそうですね。
本当かっていう気はしますけど、でもまた新しくこういうものが追加になったというようなので、これもこれでまた気になりますね。
フォント周りは結局フロントエンドの人間だと注目しなきゃいけないところではあるので、これがレイアウトシフトゼロにした自動セルフォスティックになったっていうのは結構面白い話だなと思いますね。
どういう仕組みなのかって後ほど語られると思うので、それは見てみましょう。
続いて、improveですね。next-linkっていうのが改善されましたよと。自動的なAタグっていうのを含む簡素というかシンプリファイですね。シンプルになったAPIだそうですね。
next-linkっていうタグがです。最初からAタグっていうのは普通に含んでいて、よりシンプルになったように、APIがシンプルになったよってことだそうですね。
使いたい人とか、Next.jsの最新版13を使いたい方っていうのは、npiのnext-latest、react-at-latest、react-dob-latest、eslint-config-next-latestっていうのをnpmにインストールすれば使えますよと。
冒頭からちょっとグダグダしてしまって申し訳ないんですけど、これで冒頭のところがスタートで終了して、今から1個1個の項目について詳しく述べられているのでそれを見ていきましょうというところです。
先に申し上げますと、もちろんソースコードが結構たくさん出てきたりするし、画像もペペペ貼られてますので、僕が見てて、僕はわかるんですけど、音読が聞かれている方は不運ぐらいの感覚になってしまって大変に申し訳ないですけど、そこはご了承いただければ幸いです。
あと、やっぱりですね、このブログ、今日見てパッと見たら思ったんですけど、すごく長いので、多分明日3日ぐらい続くかなっていう感じがします。というところでお付き合いいただければ幸いです。
では行きましょう。最初のNew App Directoryですね。App Directoryというのが完全に刷新されましたというところですね。これは先ほど述べた通り、だいぶ前の朝活で読んできた通りですね。
App Directoryの結構ドラスティックに構成が変わりますよというところです。
06:02
本日、私たちはNext.jsのルーティングとレイアウトの体験というのを改善しまして、App Directoryの導入でリアクトの未来と足並みを揃えていきますということです。
これは以前コミュニティのフィードバックのために公開されたレイアウトRFCのフォローアップだそうですね。
なるほど。レイアウトRFCのままいったわけではないってことですかね。それはそれでいい話になりますね。
App Directoryというのは現在ベータ版であって、まだ実運用での使用は推奨していないと言っています。
なのでまだ介護感はあるし、何なら使わない方がいいと。ただ実験的な機能で使ってみたい人は使ってみてくださいというのと、多分意見も下さいだと思います。
その資源をそのまま使いたいし、既存のディレクトリ構成のままNext.jsだけ新しくしたいという方は、以前のままでも使えるということですね。
今述べた通りですね、冒頭にあった今回新しくNext.jsに入ったものの中に、新しいNext.jsイメージと改良されたNext.jsリンクというのがあるので、これも使いたい方も全然いると思うので、これはまたいい話ですね。
Pages Directoryというのは当面の間サポートを継続する予定ですよというところがあるからこそ、ちゃんと皆さんが今まで通り使えるよということでした。
ついに導入されるし、ちゃんとNext.jsでも対応されたというので、これは熱い話ですね。
で、3つ目です。
ストリーミングですね。
ストリーミングですけど、これは瞬時にロードされる状態というのを表示して、レンダリングされるUI単位でストリーミングしますと。
これはコンセプト的には最近朝霞発で読んだそのアストロ的なものとか、あとQuickも確かそうだ気がしますけど、要は全部をいっぺんにガンって取ってくるんじゃなくて、最初に出すものは本当にペラッペラの側だけで、
必要なハンドリングだったりとかイベントハンドラーみたいなものは、いつレンダリングするかその都度その都度、それぞれのフレームワークの思想ごとによって分けようと。
ちなみにQuickはクリックされた瞬間ですね。
発音ほぼ似てるんですけど、Quickっていうフレームワークは、例えばそのボタンコンポーネントを僕らがマウスとかでクリックする操作を押すじゃないですか。
押したっていうところを取って初めて本当に必要な、だからオンクリックっていう、HTML標準のイベントハンドラーというのは、HTMLじゃないですね、JavaScriptがブラウザーでも本来標準で持っているクリックイベントハンドラーっていうのは最初にセットしておいて、
本来その先でやるQuickっていうフレームワークが持っているイベントハンドラー自体は、別で持ってるJSをその時初めて取りに行くらしいですね。
っていうことをやるので、Quickっていうのは他のJavaScriptフレームワークと比べて一番早いって言ってるんですよね。
なかなか振り切ったやり方をしてるなっていう感じですけど、そういうやり方もあれば、コンポーネント単位でどれだけ画面描画ですね、
一発のバッて出てくる画面の描画の中だけ出てくるものだけをレンダリングして、それ以外のものはまだ取りに行かないと。
ただ取りに行くっていうキーとかトリガーだけページ内でちゃんと作っておいて、スクロールしたりとかユーザーが操作したことによって連動して都度都度取りに行くとか、
09:08
そういうことですね。柔軟にできるっていうのが今最新のJavaScriptフレームワークの流れなんだなと思ってて、
Next.jsもそれに乗っかったのかなっていう感じします。ただまぁどっちが先なのかちょっとわかんないです。
NextとかReactが先にもうそれをやるぞって宣言してて、やってたっていうのが多分普通だと思います。
なんせ、Astroもそうですけど、やっぱりReactベースのものですし、QuickっていうフレームワークもJSXベースのものっていうことに変わりはないんですよね。
JSXベースってことは結局Reactとほぼ同義と言っても過言ではないので。
Reactが先にそのReactサーバーコンポーネンスをやるよってRFCで言った通りなので、それに乗っかったんだろうと思ってます。
そういうことをやるっていうのがこのストリーミングっていう元々の機能ですね。
とにかく画面描画、初期レンダリングを早く早くして、都度都度必要なものをUI単位でストリーミングをすると。
最後4つ目ですね。データフェッチングのサポートもしますよと。
非同期のサーバーコンポーネンスと拡張フェッチAPIっていうものを使って、コンポーネントレベルでのフェッチを可能にするようにしましたよとですね。
今までのクライアントベースでのフェッチではなくて、完全に非同期でサーバーコンポーネンスが今回導入されるので、それに対応したフェッチっていうのも対応してますよっていうことはそうですね。
今までみたいにSWRとかでパッて取るような感じではないんですかね。
新しいリアクト、ネクストが本来持っているフェッチAPIっていうのがありそうですね。
それぞれ4つのApp Directoryの中に含んでいるものですね。
その4つのものをここからまた詳しく言及されていってる感じですね。
というわけでまず1つ目がレイアウトってものです。
ここからいきなり画像とソースコードがすごい頻発するので、ちょっと音読。
僕は音読するんですけど、想像力豊かに聞いていただければです。
興味ある方は全然そのままNext.js13のブログですね。
公式ブログそのまま開いて読んでいただいてもいいと思います。
英語のやつは僕はそのまま翻訳して読んでるだけなので。
じゃあレイアウトの話いきましょう。
レイアウトですね。
App Directoryっていうのを使用すると、ナビゲーションは平らな状態っていうのを維持して、
コストの高い再レンダリングっていうのを回避して高度なルーティングパターンっていうのを可能にする。
複雑なインターフェースを簡単にレイアウトすることができるようになりますよと言ってます。
さらにレイアウトを入れ替えにしたりとか、コンポーネント、テスト、スタイルなどのアプリケーションコードを
ルーティングと一緒に配置することもできたりします。
その効果なっていうのは、コストが高い再レンダリングっていうのは
行ったり来たりした時に、全く同じページであれば別にキャッシュしてパッと出せばいいんですけど、
ところがどっこいジャックスクリプトはSPAなので、
実はそのページ単位でキャッシュするとは限らないし、
結局取ってきてるのって一つのHTMLで、
減らしたらバンドル一つドーンとやってきたJavaScriptなので、
ちゃんとそのチャンク分けをしない限りは、結局はフェッチするのは難しいと。
12:01
結局初期でやるような各ページの初期レンダリング用のソースコードっていうのを
キャッシュすることはもちろんできるかもしれないし、
計算後の値が完全に乗ったかもしれないもののキャッシュはできるかもしれないですね。
サーバーサイドレンダリングとかしておいて、
計算済みのもののHTMLを静的にバンとクライアント側でキャッシュすることはできなくはないですけど、
それをまた行ったり来たりしたときにまた同じ状態がパッとできるかっていうと、
そうとは限らないし、そうじゃなかった瞬間にいきなりまた全部、
あと計算し直さなきゃいけないし、
SSRだったらハイドレーションしなきゃいけないっていうので、
コストかかるっていうのは嘘いうお話ですね。
っていうのを回避することができるようになると。
なのでどういう仕組みなのかちょっと気になりますけどね。
で、画像が貼られていまして、
これは今までのLayoutsRFCと全く同じで、
そのディレクトリ名の中にPagesだったりNavbar.jsだったりNavbar.test.jsだったり、
ストーリーブック用のStories.jsだったりみたいなのを
同じディレクトリ名の中に置いといてくださいという感じですね。
やるとそれが全部URL的にスラッシュ、ダッシュボードみたいなURLとして
吐き出されますよっていう風に言ってます。
まずこれが一つですね。
いわゆるコロケーションっていうのを、
ちょっと前に浅瀬さんが言ったと思いますけど、
まさにあれのことを同じようにやってるって感じですね。
コロケーションって名前ついてますけど、
今まで僕らがよくやってきたことをそのままやってるような感じですね。
で、やり方的にも、
まずRootiesディレクトリの中に、
Appディレクトリが、違うわ。
Appディレクトリの中にRootiesっていうものを作っておいて、
その中に一個Pages.jsっていうのを作ってくださいと。
で、Pages.jsは今まで通りJSXで適当なものを返すような
関数コンポーネントを作っておけば大丈夫ですよと。
この辺までは今まで通りっていう感じですね。
本当に。
僕らがよく使うPagesディレクトリの中に適当なJSを作ったら
それがそのままPagesになりますよっていうのを、
今まではPagesの下に作ってたんですけど、
今回からAppディレクトリの下にRootiesっていうディレクトリを作って、
その下にさらにPagesっていうのを作ってくださいという感じですね。
これ別にRootiesを作るところまでデフォルトにしてもいいですけど、
単純に静的ファイル、静的なページだけを作っておく。
別にSPAじゃないようなページを作りたいという人もいなくはない
っていうところを考慮してるのかなという感じですね。
SPAを作る前提だったら確かにRootiesディレクトリまで作ってから
ボイラープレートで作ってくれれば嬉しいんですけど、
そうじゃないようなので、やりたいときはクリエイティングで
Rootiesディレクトリを作ってくださいというふうにおっしゃってますね。
続いて、ファイルシステムを通じてレイアウトを定義することもできますよと言ってますね。
レイアウトっていうのは複数のページ間でUIを共有します。
ナビゲーション時にレイアウトは状態を保持して、
インテラクティブな状態を維持しサイレンダリングを行わないと。
ナビゲーションするタイミングで今の状況のレイアウトっていうのを保持しておくと。
15:02
レイアウトって言ってるけど、その中に全部ページも入ってたりするから
結果的に全ページをキャッチすることになるのかな?わかんないですけど。
そうなるとそれはそれで結構、メモリかなり使いそうな気がするけど、
これ大丈夫なのかな?わかんないですけどね。
ファイルとかアプリケーションのコンポーネント数がめちゃめちゃ大きくなったら
果たしてどうなんだろうっていうのは気になりますね。
パフォーマンス周りがこのブログでは多分書かれてないので、
結構デカいアプリケーションをネクスト13で作った場合どうなんだろうっていうのが僕は気になりました。
一応でも一旦レイアウトの話はそんな感じですね。
今までのものを現在のレイアウト、ネクスト13で導入されたベータ版のレイアウトを作って
作りたい場合はそういうディレクトリの切り方をしてねってことはそうです。
一応その、エグザンプルがどっか適当なところにバッとリンク貼られてます。
バーセルの中にありますね。
っていうのがあるので、興味ある人はそっちの方を見てみてくださいということはそうです。
では続いてサーバーコンポーネントの話ですね。
はい、じゃあAppDirectoryですけども、
AppDirectory、あ、違うわ、翻訳し忘れました。
ちなみに30分来たんですけど、僕が今日は10分くらい遅れたので、
切りがいいところまでもうちょっと延長しながらやっていきたいなと思ってます。
はい、で、次でサーバーコンポーネントですけど、
AppDirectoryっていうのはリアクトの新しいサーバーコンポーネントアーキテクチャっていうのをサポート導入していますと言ってます。
サーバーコンポーネントとクライアントコンポーネントっていうのは、
そのサーバーとクライアントをそれぞれ得意なことに使うことで、
単一のプログラミングモデルで高速かつ高高度にインタラクティブなアプリを構築し、
優れた開発者体験っていうのを提供しますと。
あくまで開発者体験の向上を目指した話なのかな、これはそうやっていくと。
サーバーコンポーネントでは複雑なインターフェースを構築するための基礎を築きながら、
クライアントに送信されるJavaScriptの量を減らし、最初のページのロードを高速化することができます。
結果、クライアントのためにもなりますよねということですね。
で、ルートがロードされるとNext.jsとリアクトのランタイムがロードされます。
これはキャッシュ可能でサイズも予測可能なものです。
このランタイムっていうのはアプリケーションが大きくなってもサイズが大きくなることはありません。
さらにランタイムっていうのは非同期にロードされるので、
サーバーにあるHTMLをクライアントで徐々に拡張していくこともできますよと。
言ってることはわかりますけど、ちょっと僕は疑った目線で見てますね。
ただこれが本当にちゃんとできてるんだったらとてもいい話だし、
設計がドラスティックというか大きく変わる必要があるなと思いました。
それでやっぱりサーバーコンポーネントを導入するっていう風になった場合は、
今までの僕らが思っていたアプリケーションの開発と、
全然思想と思考が変わってきたりするので、
設計方針、結構ドラスティックに変えなきゃいけないと思いますね。
僕らがコンポーネント単位でどこをサーバーサイドに処理をぶん投げるかみたいなところの話とか、
どこでサーバー、どこでクライアント、何をキャッシュっていうところが、
18:03
今まではあんまり考慮してなかった。
サーバーサイドレンダリングをしている方は結構考慮したかもしれないですけど、
今はそんなにすることはなくなった。
プリレンダリングしてるっていうのがあったりしますね。
Next.jsにプリレンダリングっていう概念が途中で入ったので、
そこを使っている方もいたら近いところあるんですけど、
それがさらにコンポーネントレベルになったってなると、
結構大きい話だと思うので、
これはこれで本当に導入して使ってみたいっていう現場であれば、
最初の初期設計がかなり時間というか、
入念に寝らないといけないんじゃないかなと思いますね。
それがハマったとき、公式ブログがおっしゃってるように、
開発者体験度がかなり向上するんだろうなと思いますけど、
果たしてどうなんだろうっていうところはありますね。
なので、慣れるまではむしろ時間かかるんじゃないかっていうのが、
僕はちょっとうがった目線で見てますって感じでした。
続いて、今のがサーバーコンポーネントですね。
続いてストリーミングの話です。
ストリーミングですけど、
App Directoryっていうのは、
リアクトの新しいサーバーコンポーネント…
これはまだ翻訳されないですね。
ストリーミングです。
App DirectoryではUIのレンダリング単位を段階的にレンダリングし、
クライアントにインクリメンタルにストリーミングする機能が導入されています。
Next.jsのサーバーコンポーネントとネットされたレイアウトを使用すると、
特にデータを必要としないページの部分を即座にレンダリングして、
データを取得しているページの部分については、
ロードの状態表示することが可能になります。
いわゆるスケルトンみたいなものだったりとか、
ローディング画像をバテを張るとか、
そんなことをしたりとかできます。
Next.jsとサーバーコンポーネントのネットされたレイアウトを使用すると、
このアプローチでは、
ユーザーはページ全体がロードされるのを待たずに、
そのページとのやり取りを開示することができますよと言ってますね。
これはでもよく見たレージローディングと結構似た話だと思いますけど、
これはJava Nextでも対応しているので、
これはさらにコンポーネント内で細かく制御できるようになったということだと思いますね。
でもそれを全部待たなくても、ユーザーとしては操作ができるようになると。
全部画像までレンダリングされて、
初めて動かせるようになるというのはやっぱり遅いので、
そうじゃなくて、パーツだけでパンと置いておいて、
後から本来必要なものとかがポンポン降りてきていくというのは全然いいと思いますので。
テキストだったり、色がちょっとついただけだったら別に、
初期レンダリングでバッツサブレンダリングするので、
その辺は多少見えるようになるともちろん思うんですけどね。
というのがより細かくできたということだと思いますね。
バーセルにデプロイすると、
App Directoryを使用するNext 13のアプリケーションはパフォーマンスを向上させるために、
Node.jsとEdgeの両方のランタイムでデフォルトでオートストリームするようになります。
こういうところがやっぱりバーセル上にNext.jsで作ったアプリをアップする一つのメリットですよね。
やっぱりバーセルって、Next.js自体がバーセルで作っているものなので、
今、Next.jsのアプリケーションをデプロイする先に、
21:02
バーセルがその辺を手厚くサポートするのはそりゃそうだよねって感じです。
使ってね、僕らをっていうことだと思うので。
本当にパフォーマンスを向上させるためだったりとか、
そのNodeとかのうまいこと、ランタイムを連携させたり、
オートストリームしたりになれば、
Next.jsで作っているアプリケーションを今はバーセルに上げて、
ドメインを後で張り替えるっていうのも選択肢としてありかもしれないなと思いました。
本当に早いのかどうかっていうのは要検証は必要だと思いますので、
これはこれで別途検証はしたいなと思いますが、
毎回こういうこと言ってしないので、
どなたかやってくださることを待つし、
海外の方がやってくださることを僕は期待しています。
で、次4つ目、ラストですね。データフェッチングのところです。
多分今日の朝方は一旦これで終了かな。
そのAppDirectoryベータってところだけで話は終わりそうですね。
ラストデータフェッチングのところですけど、
リアクトの最近のサポートフォープロミスRFCっていうものでは、
データをフェッチしてコンポーネント内でプロミスを処理するための強力な新しい方法というのを導入しています。
一応ソースコードがバッて載ってるんですけど、
使い勝手としては今までとほぼ変わってないですね。
awaitしてフェッチっていうのがデフォルトのES6の関数ですけど、
そして受け取ったレスポンスのオブジェクトのres.jsonですね。
JSONメソッドにかけて、ちゃんとJSON型に変換をするというのが今までのやり方だったんですけど、
これが新しくASyncのサーバーコンポーネントの方のフェッチのやり方ですけど、
同じようにawaitでgetデータっていうところですね。
サーバーコンポーネントの方では今言ったクライアント側の標準のフェッチAPIを使ったAPIコールっていうところを、
そのまんまサーバー側でawaitでコールしてあげて、
それを使えば良いという風に言ってますね。
へー。
ってことはこの今フェッチって書いてるAPIはNextのフェッチかもしれないですね。
ES6以降のJavaScriptが持っているフェッチじゃなくてNextのフェッチっていうことですね、これは。
ちょっと名前が紛らわしいですけど。
はいはいはいはい。
いずれNextが作ったフェッチAPIが標準になってくれみたいなところがあるのかもないのかも分からないです。
思惑があるのか分からないですけど。
とりあえず同じ名前で出してるっぽい?
言及はされてないですけど、感じはしますね。
だからそのまんまクライアント側のフェッチ用の切り出した関数コンポーネントをそのまんま読んで、
そのまんまawaitで読んでみればデータを取れるよってことだそうですね。
ネイティブのフェッチWebAPIっていうものはリアクトのNext.jsでも拡張されましたと。
これはフェッチ要求を自動的に重複排除して、
コンポーネントレベルでデータをキャッチ、キャッシュ、そしてサイバリデートする柔軟な方法を一つ提供するものです。
なるほどね。
ちゃんとラップしてその辺を制御していると。
なので公式のほうではなくてデフォルトでちゃんとNextが提供しているフェッチAPIをちゃんと使うようにしてあるし、
24:00
キャッシュもするし、バリデートもするしってところそうですね。
さらに静的サイトですね。
SSGだったりとかサーバーサイトレンダリングだったりとかISRですね。
インクリメンタル静的サイト。
せいせいなところですね。
このところ全ての利点がその一つのURLフェッチというAPIを通じて利用可能になったよってことを意味してますということですね。
単純に使い方もフェッチで第一引数にURLを渡して第二引数にキャッシュでフォースキャッシュしたりとかノーストアやったりとか
リバリデート10とか指定したりとかそんなことができるようになりますと。
これが続いていって、もうちょっと画像が続きますけども。
App Directoryではレイアウトだったりページだったりコンポーネントの内部でデータを取得することも全然できますと。
どのレイヤーとかどの単位でもデータを取得することが柔軟にできるようになりますよってことですね。
サーバーコンポーネンツっていう概念が入ったのです。
そこでさらにデータを取れるんであればそれはそうだよね。
私たちはそのローディングとエラーの状態を処理する人工学的、人間工学的な方法とレンダリングされるUIのストリーミングというのを可能にしています。
将来のリリースではそのデータの変異とか改善と簡素化というのをもうちょっと行う予定だそうですね。
今ならもうちょっと複雑性が入ったりとか、制御をちょっと頑張らなきゃいけないというところがあるので、僕はもうちょっと改善の余地がある。
だから今まだApp Directoryっていうところがベータ版なんだろうなって思いますね。
逆に言うとこれを入れればサーバーコンポーネンツも使えるようになるので、アーリアダプターの方々はこの辺を使ってみたらいいんじゃないかなというところですね。
前途が聞いたみたいな、誰かしら書いてる気はしますけどね。
ちょっと見てみたいと思いますけど。
最後、私たちはオープンソースコミュニティ、パッケージメンテナー、およびリアクトエコシステムに貢献している他の企業とともに、
リアクトとNext.jsのこの新しい時代のために構築することに結構興奮しています。
データ取得をコンポーネント内に配置する機能と、クライアントへのJavaScriptの配布を減らす機能というのはコミュニティからのフィードバックのうち、
App Directoryを含めることができた重要な2つの部分ですよというふうにおっしゃっています。
ちゃんといろんなところから、方々からの意見をもらったりとか、コミュニティからのフィードバックを得て、いろんなものを設計してるって言いましたね。
それは多分そうだろうと思ってましたけど、その上でこうなったっていうので、いろんな人たちの意見を踏まえてこれを、
結構ですね、レイアウトRFCを見た瞬間、プルリクエストを見た時って当時ですら結構反対意見も多かったんですよね。
なのでそれでも恒例に走ったってことは、やっぱりこのバーセル社の方々はこの設計が今のNext.jsとしてはいいんだろうなっていうふうに考えたものがあるっていうことだと思うので、
これは多分後ほど出てくるかなというとちょっと怪しいですね。どっち方出てくるかはちょっと難しいですけど、
やってみたら分かってくるものもやっぱりあると思うので、地面だけ見てふーんって分かるものではこういうものはないと思いますので、
後ほどまだ自分たちの方でもいろんな人が触ったっていう結果だったりとか、自分たちでも触ってみた経験から、やっぱり良かったっていうのが分かるかもしれないので。
最終的にフレームワークの良し悪しっていうのは、誰かの記事が決めるものじゃなくて、歴史が決めるものなので、それは待ってみればいいと思います。
27:07
それを待ってから触るのもいいですし、とにかくどんどん新しいものをチャレンジするというところで、地雷を踏みに行ってOSSコミュニティに貢献するんだみたいな話でもどちらの意味かと思いますけど。
今のところとりあえず自由さに挙げても今までのバージョンのディレクトリ構成でもできるし、新しいバージョンはベータ版として導入もできます。
どっちでもいいですよってお話でした。
はい、というところでちょっと41分で少しオーバーしてしまいましたけど、今日の朝勝はここでいたたき切らせていただきたいと思います。
久しぶりの朝勝でだいぶグダグダしてしまって大変に申し訳なかったですけど、また明日の続きですね。
明日はそのターボパックってやつですね。
今アルファ版で同級になったターボパック。
ウェブパックから何百倍速くなったと言っているホンマかいなっていう噂のターボパックですね。
ビートより10倍速いと言ってます。
本当かよって、いまだにちょっと僕は信じられないですけど。
というところから明日を入っていきたいなと思っています。
はい、じゃあ今日の朝勝は以上で終了したいと思います。
月曜日ですね、朝5時からは。
え、月曜日じゃないですね。
今日は木曜日でしたね。
というところですけど、1日あげて休みます。
木、金ですね。
あと2日間頑張っていけたらなと思います。
じゃあ今日も、今日はですね大地さんと羽月さんですね。
はいご参加いただきありがとうございました。
また明日も興味があれば参加していただければ幸いです。
じゃあ朝勝終了したいと思います。お疲れ様でした。
