Next.js
Overview
Reactをベースにしたフレームワークで、フロントエンド開発を効率化するための機能を提供しているフレームワーク。
Next.jsでCSR・SSR・RSCの扱い
SPAで軽視されがちな部分
Next.js API RouteとgetServerSideでCookieを参照するには
Reactとの違い
ブラウザは受信したJSファイルを処理することでh1タグとその内容を描写していることがわかる ブラウザ ページソースを確認すればわかる
Client Rendering 検証でソースコードを見ると、h1タグなどは出現しない。 JSをブラウザが処理している
Server-side Rendering 検証でソースコードを見ると、h1タグなどがある。 JSをNextがpre-Renderingをおこなっているため
Next強み
Nuxtだと、SSRにした場合はすべてのページがSSRとなってしまうが
Nextだと、このページはCSR、次はSSRなど分けることができる。もちろんSSGも
Next.jsの大きな特徴として、ひとつのプロジェクトの中で、SSGとSSRを混在して利用することができる
API Routeでcookieを設定する方法
Next JS Client と Express Server によるセッション Cookie の処理
Next.jsのdefault cache
各コマンド仕組み
$ npx next -h
で各コマンドの詳細を確認できる
$ next dev
ローカルでアプリケーションを起動します。
getStaticProps
(SSGで利用するmethod)を利用した場合でもSSR動作になる。
このコマンドでは、ホットリロードやエラーレポートなどの開発モードでアプリケーションを起動できる
ただし、create-next-appでスキャフォールディングしたプロジェクトに用意されているdevコマンドで起動したアプリはサーバーサイドレンダリング(以下SSR)が有効になっており、静的HTMLのみの確認ができない
そこでNext.jsで静的HTMLエクスポートしたアプリをローカルで確認する方法を調べました。 参考URL
$ next build
.nextフォルダーにプロダクション用のコードを吐き出す
本番用に最適化されたビルドを行い、各ルートの情報がコンソールに出力されます。
$ next start
このコマンドは next build
でビルドした後に実行すると、本番用としてサーバが立ち上がる。
プロダクション環境でアプリケーションを実行する
envはproduction
$ next export
outディレクトリに静的HTMLをエクスポートする。
サーバーにNode.jsを必要とせずにクライアントのみで実行できる静的HTMLを出力する。
localで確認する場合は
$ yarn add -D serve
というパッケージをインストールする
※静的ファイルをホスティングするローカルサーバ
各メソッド
ついでにuseSWRを利用してデータを取得してみます。 SWRはRenderingの種類ではない。Stale-While-Revalidateというキャッシュ戦略の略。
SWRとは
Vercelが開発する、HTTP RFC 5861で提唱された、SWRというキャッシュ無効化戦略に基づくライブラリ。 簡単に言うと、最初は普通にデータを取得してキャッシュとしてセット、次に参 照された時にいったんキャッシュを返し裏でまたフェッチして、フェッチが完了したらキャッシュを最新のものに置き換えるというキャッシュ戦略をよしなにやってくれる。
Next.jsにimport React from 'react'はいるのか?
参考URL
結論いらない。
pages/apiとは(API Route)
next.jsでは pages/api
ディレクトリ以下にTypeScript (JavaScript) コードを配置するだけで、クライアントサイドJavaScriptから呼び出せるAPIを定義できる。
※pages/api
ディレクトリ以下の実装内容がクライアントに見られてしまうことはない。
- サーバーレス関数として配置される
注意
サーバーからデータを取得したい場合にAPI ルートにアクセスしてから、その API ルートを呼び出したいと思うかもしれませんgetServerSideProps。getServerSidePropsこれは不要で非効率的な方法です。サーバー上で と API ルートの両方が実行されているために、余分なリクエストが行われることになるからです。
とあるように getServerSideProps
からAPI Routeへアクセスするのは冗長(同じNode.jsプロセス内のため)
middleware
ミドルウェアは、一連のページのロジックを共有するあらゆるものに使用できる そこで、Next.js 12からは、ミドルウェアとしてエッジ関数(AWSのLambda@Edge的なもの?→中身はCloudflare Workersらしい)が導入されました。
エッジ関数は、リクエストが完了するまえにコードが実行できる。 クライアントとオリジンサーバーの間にエッジサーバーをおき、エッジ関数としてデプロイ。 エッジ関数は、認証、ボット保護、リダイレクト処理、サポートされていないブラウザ、機能フラグ、A/Bテスト、サーバー側の分析、ロギングなどあらゆるものに使用できる。 使い方は簡単で、 _middleware.tsを配置し、そのファイルに処理を書くだけです。
つまり、 VercelにReact Server Components (Next.js 12版)をデプロイするなら、それはミドルウェア上で(エッジ関数として)動作する、サーバーレスとして動くということらしいです 。
/pages/_middleware.js(ts)ファイルが作成されている場合、/pagesディレクトリ以下すべてのページ(route)で実行される。
Next.jsでv12~ middlewareという機能が使えるようになった。 middlewareに書いた処理はリクエストが完了する前に実行される。 Cookieの値に応じてルーティングを振り分けたり、Basic認証を導入したりなど幅広い用途で使えそう。
Tips Vercelでホスティングをすると相性が良い。 VercelとNext.jsの組み合わせが強いのは、VercelにNext.jsをデプロイするとこのmiddleware部分をEdge Functionsで捌いてくれるという点です。つまり、静的なページに対するリクエストに対して、オリジンサーバーに触れことなくmiddlewareを実行できるということです。
_middleware.jsファイルが複数のディレクトリに配置されている場合は、階層が浅い方から順に実行されていく。
_document.js(tsx)によるカスタマイズ
Next.jsのPageコンポーネントはデフォルトでは <html> & <body>
タグの定義を行うが、それらを拡張したい場合は_document.js(tsx) を作成し、その中でDocumentコンポーネントを継承したクラスを実装す る。
注意点
- SSR(サーバサイドレンダリング)のみの実行
next/image
next/image
が自身で持っている画像サーバが処理をしてくれるようになる。
仕組みとして、next/image
画像配信用のエンドポイントを立ててそこから配信される。
エンドポイントとしてのURLは以下となる。
https://igsr5.dev/_next/image?url=OOOO
このURLの中にある _next/image
がデフォルトで持つ画像配信用のエンドポイント。
ンドポイントがリクエスト毎に画像加工やキャッシュなどを行っています。反対にビルド時には画像の加工は行われておらず全てオンデマンドで行われている。
気をつけポイントとしてVercel以外でNext.jsをデプロイするときに _next/imageもアクセス可能な状態にしておくことが挙げられます。(_next/ 配下は他にもNext.js的に大事なエンドポイントが詰まっているのでミスらないためには _next/* で公開してしまうのもあり)
- レイアウトシフトが起きない
- サーバサイドでの画像リサイズ
- 適切な画像サイズの算出
- Lazy Loadが有効(特徴としてはNative Lazy LoadingではなくJS Lazy LoadingのためSafariなどのブラウザでも有効である。)
注意点 next/imageでは必ずしも指定したサイズの画像が返ってくるとは限らない。 next/imageでは画像の表示領域やユーザのディスプレイ解像度に合わせて適切な画像サイズを返す。
next/imageを仕事で使う際に気をつけたい仕様
Tips
かなりのTipsが散りばめられている nextの仕組みを読み解く
外部ライブラリの利用
ときおり普通のReactで動くライブラリがNext.jsでビルドすると動かなかったりします。 こうした場合は、動的インポート(Dynamic Import)という機能で対処できる場合があります。動的インポートしたコンポーネントはクライアントサイドでレンダリングされるため、実質的にReactと同じように処理されるためです。
styled-components
Next.js(12): SWCには自動で組み込まれている Nextリファレンス(12) styled-components リファレンス
CSSの記述はSassと同じネストによる記述が可能
CSS in JSを使う意味の主なものとしては、 メンテナンス性の向上と、パフォーマンスの向上 JavaScriptフレームワークではコンポーネント単位でソースを管理することが一般的。 CSSを別管理でひとまとめにするよりもコンポーネントとセットで管理したほうがCSSの記述箇所を見つけやすくメンテナンス性が高くなる。
またCSS in JSを使うと、表示中の要素だけCSSを書き出し不要なCSSを書き出さないという処理が可能になるためパフォーマンス性が上がる。 またSEOの評価も上がる。
ThemeProviderの利用 styled-componentsにはThemeProviderというAPIがあります。これはContext APIを使って、子のコンポーネントに、propsでスタイルを渡すことができます。 これで、スタイルを共通化できる。 ThemeProviderは、_app.jsで使用する。