https://nextjs.org/blog/next-14
雑に翻訳しました。
意訳がめちゃくちゃ含まれているので注意です。
Next.js Confで発表したとおり、Next.js 14 は、下記の点に最も重点を置いたリリースです。
今すぐアップグレードするか、次のコマンドで新規作成出来ます。
npx create-next-app@latestNext.js 13以降、私達はNext.jsのPagesRouterとAppRouterの両方で、ローカル開発のパフォーマンスを向上させるように取り組んできました。
以前は、この取り組みをサポートするためにnext devやNext.jsの他の部分を書き直していました。しかし、後に私たちはより段階的なアプローチに変更しました。これは、私たちのRustベースのコンパイラが近いうちに安定性に達することを意味し、今後全てのNext.jsの機能をサポートすることに焦点を当てています。
next devに関する5000件の統合テストが、基盤となるRustエンジンであるTurbopackで現在合格しています。これらのテストには、7年分のバグ修正と再現テストが含まれています。
大規模なNext.jsアプリケーションであるvercel.comでテストしている間、下記の事を確認しました。
このベンチマークは、大規模なアプリケーション(および大規模なモジュールグラフ)を使用する際に期待されるパフォーマンスの実験的な結果です。現在、next devのテストの90%が合格しているため、next dev --turboを使用すると、より高速で信頼性の高いパフォーマンスを一貫して確認できるはずです。
100%のテストに合格したら、次回のマイナーリリースでTurbopackを安定版に移行します。また、カスタムコンフィグやエコシステムプラグインのためのWebpackの使用も引き続きサポートします。
テストの合格率はareweturboyet.comで確認できます。
Next.js 9では、フロントエンドのコードと一緒にバックエンドのエンドポイントを素早く構築できるAPI Routesが導入されました。
たとえば、api/ディレクトリに新しいファイルを作成します。
importtype{ NextApiRequest, NextApiResponse}from'next';exportdefaultasyncfunctionhandler( req: NextApiRequest, res: NextApiResponse,){const data= req.body;const id=awaitcreateItem(data); res.status(200).json({ id});}そして、クライアント側では、ReactでonSubmitのようなイベントハンドラを使って、API Routeをfetchすることができます。
import{ FormEvent}from'react';exportdefaultfunctionPage(){asyncfunctiononSubmit(event: FormEvent<HTMLFormElement>){ event.preventDefault();const formData=newFormData(event.currentTarget);const response=awaitfetch('/api/submit',{ method:'POST', body: formData,});// Handle response if necessaryconst data=await response.json();// ...}return(<form onSubmit={onSubmit}><input type="text" name="name"/><button type="submit">Submit</button></form>);}Next.js 14では、データの変更を簡素化することで開発者のエクスペリエンスを向上させたいと考えています。さらに、ユーザーが遅いネットワーク接続を持っている場合や、低性能なデバイスからフォームを送信する際のユーザーエクスペリエンスを向上させたいと考えています。
API Routesを手動で作成する必要がないとしたらどうでしょうか?
その代わりに、サーバー上で安全に実行される関数を定義し、Reactコンポーネントから直接呼び出すことができます。
App Routerは、フレームワークが新機能を採用するために安定したReactCanaryの元で構築されています。Next.js 14では、現在最新のReactCanaryにアップグレードされており、安定したServer Actionsが含まれています。
以前のPages Routerの例は、1つのファイルに簡略化できます
exportdefaultfunctionPage(){asyncfunctioncreate(formData: FormData){'use server';const id=awaitcreateItem(formData);}return(<form action={create}><input type="text" name="name"/><button type="submit">Submit</button></form>);}過去にサーバー中心のフレームワークを使用したことのある開発者にとって、Server Actionsは馴染みがあるはずです。これはフォームやFormData Web APIなどのウェブの基本に基づいて構築されています。
フォームからServer Actionsを使用することは、Progressive Enhancementに役立ちますが、必須ではありません。フォームを介さずに、関数として直接呼び出すこともできます。TypeScriptを使用する場合は、クライアントとサーバーの間で完全にE2Eの型安全性が確保されます。
データの変更、ページの再レンダリング、リダイレクトを1回のネットワーク・ラウンドトリップで行うことができるため、上流のプロバイダーが遅い場合でも、正しいデータがクライアントに表示されます。さらに、異なるアクションを構成して再利用することができ、同じルート内に多くの異なるアクションを含むことができます。
Server Actionsは、App Router自体に深く統合されており、下記のことが可能です。
revalidatePath()やrevalidateTag()でキャッシュされたデータを再検証する。redirect()で異なるルートにリダイレクトする。cookies()によるクッキーの設定と読み込み。useOptimistic()による楽観的なUI更新の処理。useFormState()でサーバからのエラーを捕捉して表示する。useFormStatus()でクライアントの読み込み状態を表示する。フォームとServer Actionsによる変更、または、Server ComponentsとServer Actionsのセキュリティ モデルとベストプラクティスについては、こちらを参照してください。
Next.jsで取り組んでいる、高速な初期静的レスポンスを持つ動的コンテンツのためのコンパイラ最適化である「Partial Prerendering」のPreviewを共有したいと思います。
Partial Prerenderingは、サーバーサイドレンダリング(SSR)、静的サイト生成(SSG)、およびインクリメンタルな静的再検証(ISR)に対する10年にわたる研究と開発に基づいて構築されています。
皆さんのご意見をお聞きしました。現在、ランタイム、設定オプション、レンダリング方法など、考慮しなければならないことが多すぎます。静的なスピードと信頼性を求める一方で、完全に動的でパーソナライズされたレスポンスもサポートしたいと考えています。
グローバルに優れたパフォーマンスを発揮し、パーソナライズを実現するためには、複雑さを犠牲にするべきではありません。
私たちの課題は、開発者が学ぶべき新しいAPIを導入することなく、既存のモデルを簡素化し、より良い開発者体験を生み出すことでした。サーバーサイドコンテンツの部分的なキャッシュはこれまでもありましたが、これらのアプローチは、私たちが目指す開発者体験とコンポーザビリティの目標を満たす必要があります。
Partial Prerenderingには新しいAPIを覚える必要はありません。
Partial PrerenderingはSuspense Boundaryにより定義されます。その仕組みは次のとおりです。次のようなeコマースページを考えてみましょう。
exportdefaultfunctionPage(){return(<main><header><h1>My Store</h1><Suspense fallback={<CartSkeleton/>}><ShoppingCart/></Suspense></header><Banner/><Suspense fallback={<ProductListSkeleton/>}><Recommendations/></Suspense><NewProducts/></main>);}Partial Prerenderingを有効にすると、このページは<Suspense />の境界に基づいて静的なシェルを生成します。React Suspenseのfallbackは事前にレンダリングされます。
シェル内のSuspenseフォールバックは、その後、Cookieを読み取ってカートを決定したり、ユーザーに基づいてバナーを表示したりするような、動的なコンポーネントに置き換えられます。
リクエストが行われると、静的なHTMLシェルが即座に提供されます。
<main><header><h1>My Store</h1><divclass="cart-skeleton"><!-- Hole --></div></header><divclass="banner"/><divclass="product-list-skeleton"><!-- Hole --></div><sectionclass="new-products"/></main><ShoppingCart />はユーザーセッションをCookieから読み取るので、このコンポーネントは静的シェルと同じHTTPリクエストの一部としてストリームされます。追加のネットワークラウンドトリップは必要ありません。
import{ cookies}from'next/headers'exportdefaultfunctionShoppingCart(){const cookieStore=cookies()const session= cookieStore.get('session')return...}さらに詳細な静的シェルを作成するには、Suspense Boundaryを追加する必要があるかもしれません。しかし、現在すでにloading.jsを使用している場合、これは暗黙のSuspense Boundaryであるため、静的シェルを生成するために変更は必要ありません。
Partial Prerenderingは現在アクティブに開発中です。今後のマイナーリリースで、さらなるアップデートをお伝えする予定です。
ページのコンテンツがサーバーからストリーミングされる前に、ビューポート、カラースキーム、テーマに関する重要なメタデータをまずブラウザに送信する必要があります。
これらのメタタグが最初のページコンテンツと一緒に送信されるようにすることで、スムーズなユーザーエクスペリエンスを実現し、テーマカラーの変更によってページがちらついたり、ビューポートの変更によってレイアウトがずれたりするのを防ぎます。
Next.js 14では、ブロッキングと非ブロッキングのメタデータを切り離しました。メタデータの一部はブロッキングであり、非ブロッキングのメタデータが静的シェルの提供を妨げないようにしたいと考えています。
以下のメタデータオプションは現在非推奨となり、将来のメジャーバージョンからは削除される予定です。
viewport: ビューポートの初期ズームとその他のプロパティを設定します。colorScheme: ビューポートのサポートモード(明暗)を設定します。themeColor: ビューポートの周りのクロム(ブラウザの枠など)がレンダリングされる色を設定します。Next.js 14からは、これらのオプションに代わる新しいオプションviewportとgenerateViewportがあります。他のすべてのメタデータオプションは変わりません。
今日からこれらの新しいAPIを採用することができます。既存のメタデータオプションは引き続き使用できます。
本日、Next.js Learnの新しい無料コースをリリースしました。
Next.js Learnは何百万もの開発者にフレームワークの基礎を教えてきました。そして、私たちは新しい追加のコースについてのあなたのフィードバックを楽しみにしています。コースを受講するには、nextjs.org/learnにアクセスしてください。
next-swcビルド用のWASMターゲットを削除しました。(PR@next/fontのサポートを廃止し、next/fontが採用されました。 (Codemod)ImageResponseのインポートをnext/serverからnext/ogに変更しました。 (Codemod)output: 'export'を使用してください。(Docs)next/imageのonLoadingCompleteは非推奨となり、onLoadが採用されました。next/imageのdomainsは廃止され、remotePatternsが使われるようになりました。fetchのキャッシングに関するより詳細なロギングが有効になりました。(Docs)\ PrAha Challenge 第11期生 募集中!/
☆☆☆
\ エンジニア募集中! /
バッジを受け取った著者にはZennから現金やAmazonギフトカードが還元されます。
