シンセイサクシツ ログ > Javascript > Next.js のチュートリアルのメモ
Posted： Javascript Next.JS

Next.js のチュートリアルのメモ

NEXT.JS

Next.js のチュートリアルを学習しながらの雑なメモ。
現時点ではバージョンは15。

Next.js チュートリアル

chapter 1 で学んだこと｜pnmp とディレクトリ構成

パッケージマネージャーは、pnpm を推奨してる。

ディレクトリ構成

  • /app : ルートやコンポーネントを編集する一番作業するディレクトリ。
  • /app/lib : アプリで使用する再利用関数、データ取得関数、プレースホルダーデータ（ダミーのDBデータ）などを管理。
  • /app/ui : アプリのUIコンポーネントを管理。
  • /public : 画像のような静的なアセット。
  • next.config.ts : プロジェクトのコンフィグ。

chapter 2 で学んだこと｜Next.js の css

CSS は Tailwind と CSS modules を基本で使える。特に Tailwind を推奨しているように見えるけど、現時点では個人的に少し気持ち悪く感じる。他にも CSS-in-JS や普通の sass も使える。
CSS modules がいいかも？

clsx というライブラリーを使うと、状態の応じて className のCSSクラスを付け替えることができる。

chapter 3 で学んだこと｜画像とフォントの最適化

  • next/font コンポーネントを使い、ビルド時にフォントを静的アセットにして最適化する。
  • next/image コンポーネントを使い、ビルド時に画像を最適化する。

chapter 4 で学んだこと｜layout.tsx と page.tsx

ページ構成について

ページは /app ディレクトリ以下に page.tsx を作る。 /app ディレクトリがルートになる。
サブページはそのページのディレクトリを作成しその中に page.tsx ファイル作る。
例）http://localhost:3000/customers/ であれば /app/customers/page.tsx の構成になる。

レイアウトについて

サブディレクトリの page.tsx と同じ階層に layout.tsx を作成すると、自動的に page.tsx が props として渡り、layout.tsx の {children} の部分に表示される。
さらに下層のディレクトリにある page.tsx の場合、同階層に layout.tsx 無いと上階層の layout.tsx のレイアウトが使われる。

/app 直下の layout.tsx はルートレイアウトであり、Next.js の全てのページで共通で使用される。

ページ遷移時には、page.tsx のみがレンダリングされ layout.tsx で共通化されている部分はレンダリングされない。

chapter 5 で学んだこと｜Link コンポーネント

<Link> コンポーネントについて

Next.js では <a> タグの代わりに <Link> コンポーネントを使う。
<Link> コンポーネントを使うと <Link> コンポーネントが表示された時に、リンク先のコードが事前に読み込まれるのでページ遷移が高速になる。
自動コード分割とプリフェッチングという。

現在のページのパスを取得する

usePathname() を使うことで、現在ユーザーが見ているページのパスを取得することができる。
usePathname() は React のフックなので、クライアントコンポーネントに変換する必要がある。
使用するファイル内の最上部へ ‘use client’ 追加し、next/navigation から usePathname() をインポートする。

chapter 6 で学んだこと｜GitHub と Vercel と Neon

GitHub と Vercel を連携させる

GitHub 上のリモートリポジトリにアップし、その GitHub のリポジトリを Vercel と連携設定しデプロイする。

Neon（Postgre Database）を使えるようにする

Vercel のデータベース機能の一つ Neon を作成して、Next.js のプロジェクトから接続する。
.env ファイルは、git にトラッキングされないようにするために .gitignore に記述されているかを確認する。

chapter 7 で学んだこと｜データベースからデータ取得（フェッチ）

データベースからのデートの取得について

Next.js でデータを取得するときのデフォルトは React Server Components。
他に APIレイヤー を作成し、fetch でエンドポイントからデータを取得することができる。API は複数のページや外部アプリで再利用したい時に便利。
クエリを実行するには postgres.js ライブラリーと SQL を使う。

リクエストウォーターフォール

条件違いの複数のデータを SQL で同時にリクエストする場合に await を使って順番に取得していくこと。
先に取得したデータが次のリクエストに必要などのケースもあるが、基本的には順番待ちになるのでパフォーマンスが悪くなる。

パラレルデータフェッチング（並行データ取得）

promise.all を使うことで同時に条件違いのリクエストをし、全て取得するまで待つことができる。
ただし、1つだけ極端に遅いリクエストがあった場合に全体に影響がある。

chapter 8 で学んだこと｜Static Rendering と Dynamic Rendering

Next.js のレンダリングにはデプロイ時に静的ページを生成するスタティックレンダリングと、取得している情報が変更されるとリアルタイムで表示も更新されるダイナミックレンダリングがある。

Static Rendering

リアルタイムで更新しないプログやプロダクトページに向いている。

Dynamic Rendering

ダイナミックレンダリングには、以下のような利点がある。

  • リアルタイムで頻繁にデータが変更されるアプリケーション。
  • ページユーザーの操作に基づいてデータを更新するような、ダッシュボードやユーザー固有ページ。

ダイナミックレンダリングを使用すると、リクエスト時に Cookie や URL 検索パラメーターなどの情報にアクセスできる。

chapter 9 で学んだこと｜loading.tsx と Suspense を使ったストリーミング

ストリーミング

データを小さく分割しサーバーからクライアントに段階的に転送すること。
フェッチでデータ取得に時間のかかる時に使うといい。
loading.tsx または Suspense を使用した方法がある。

ローディング中はフォールバックでスケルトン（簡易的なコンポーネント）表示をする。

loading.tsx

loading.tsx は特別なファイル名でージレベルでのストリーミング。
作成するとその階層以下のページに適応される。

サイドバーなどは普通のコンポーネントで、コンテンツ部分全体に適応する場合には使う。自動的に Suspense が作成される。

Suspense

コンポーネントレベルの細かいコントロールができる。
ページ全体の表示がデータフェッチングしている遅いコンポーネントに影響される場合などに、その部分に Suspense を使うことにより、ページ表示のブロッキングを防ぐことができる。

ルートグループ

Next.js の URL は基本的にディレクトリ構成になるが、ディレクトリ名に () をつけた場合には、そのディレクトリは URL の階層としては無視される。
loading.tsx などその階層以下に適応させたく無い場合にはルートグループを使って上手く分けす。

Next.js Route Groups

chapter 10 で学んだこと｜Partial Prerendering (PPR)

パーシャルレンダリングとは、静的レンダリング、動的レンダリング、ストリーミングを組み合わせてレンダリングする方法。
Next.js 15 ではまだ実験的な機能で、本番環境では推奨されていない。が、将来的には Next.js のデフォルトのレンダリング方法になるかもしれない。

PPR は next.config.ts と layout.ts に設定を記述を追加すれば、基本的にコードを変更する必要がなく、ルートの動的な部分を Suspense でラップしている限り、静的な部分と動的な部分を自動で認識して動作してくれる。

chapter 11 で学んだこと｜useSearchParams, usePathname, useRouter フック

検索で使うフックの機能

  • useSearchParams：現在の URL のパラメーターにアクセスできる。
  • usePathname：現在の URL のパス名を読み取ることができる。
  • useRouter：現在のルートに関連する機能や情報を取得・操作する。ページを移動などできる。

URL を使い検索機能を実装

上記の フック（API） を使って検索用の input に入力したテキストを onChange でリアルタイムに取得し、useRouter を使って URL に反映させ、その URL の検索クエリにマッチした情報を表示するようにした。

検索入力をする search.tsx は、イベントリスナー(onChange) とフックを使うのでクライアントコンポーネントにする ‘use client’ をファイルの先頭に付ける。

URL 検索パラメータを使用する利点

  • ブックマークや共有可能なURL：ーザーは検索クエリやフィルターを含むアプリケーションの現在の状態をブックマークし、後で参照したり共有したりすることができる。
  • サーバーサイドレンダリング：URL パラメータをサーバー上で直接使用して初期状態のレンダリングできるため、サーバー レンダリングの処理が容易になります。
  • 分析と追跡：検索クエリとフィルターを URL に直接含めることで、追加のクライアント側ロジックを必要とせずにユーザーの行動を追跡しやすくなる。

入力時の onChange で発火を制御する

input に onChange だとキーを打つごとに発火するのでデバウンス処理をして、キーを打つがストップして 500ms 経過すると発火するように制御する。 useDebouncedCallback を使うと簡単に設定できる。

chapter 12 で学んだこと｜React Server Actions

React Server Actions

サーバーアクションは form 要素の action 属性に関数を設定して、直接サーバー関数を呼び出す。（API ルートを作ってフェッチを使わずにサーバー側で処理を実行できる。）

‘use server’

サーバーアクションを記述する actions.ts は先頭に ‘use server’ ディレクティブを付ける。以下のようなサーバー専用の処理を簡単にできるようになる。

  • データベース操作
  • 外部 API のコール（サーバー側でのみ処理し、クライアントに API キーを公開しない）
  • フォームの処理（クライアント側から安全にデータを受け取る）

FormData

関数側はキャプチャされた FormData オブジェクトを自動的に受け取り、アクション内でデータの検証などを行い sql でデータベースへ保存や変更、削除ができる。

データの検証と変更

入力されたデータは formData オブジェクトから formData.get() で抽出して、データベースへ保存に適した形式か検証し必要であれば変更をする。

検証は手動でも可能だがチュートリアルでは Zod という TypeScript First で検証できるライブラリーを使用する。

SQL でデータベースに保存

‘postgres’ をインポートして、検証したデータを sql 文で保存。

revalidate と redirect

保存した後 revalidatePath(‘path’) を行いそのパスに関連したキャッシュを削除しリダイレクトする。
recalidatePath() をしないと追加したデータ保存前の状態がキャッシュされているので、保存したデータがすぐに表示されない。

サーバーアクションに id を渡す場合

既にデータベースに保存されているデータを変更や削除する場合に、サーバーアクションに id を渡したい場合があるが、form の action で呼んでいる関数の引数として渡すことはできない。代わりに Javascript の bind を使う。

// NG
return (
<form action={updateInvoice(id)}>
...
)
// OK
const updateInvoiceWithId = updateInvoice.bind(null, invoice.id);
return (
<form action={updateInvoiceWithId}>
...
)

chapter 13 で学んだこと｜エラーの処理

エラーの処理には error.tsx と notFound 関数を使う2つがある。

error.tsx

error.tsx はキャッチされていない例外をキャッチするのに役に立つ。ルートセグメント内のエラーをキャッチして、フォールバックUIを表示できる。
エラーを適切に処理できるように、エラーを検出したいで try/catch を使う。（データベースからデータ取得時など）

error.tsx はクライアントコンポーネントとである必要があるので、ファイルの先頭に ‘use client’ を追加する。

error.tsx は、error と reset の2つのプロパティを受け入れる。

// error.tsx

use client';

export default function Error({
  error,
  reset,
}: {
  error: Error & { digest?: string };
  reset: () => void;
}) {

...

}

notFound 関数

notFound 関数は存在しないリソースを取得しようとする時にも使える。
以下のように条件式で呼ぶ。
not-found.tsx で、エラー時のフォールバックページを作成できる。

// not-found.tsx

import { notFound } from 'next/navigation';

if (!invoice) {
 notFound();
}

notFound 関数は error.tsx よりも優先度が高いので、より具体的なエラーを処理したい時に使用できる。

chapter 14 で学んだこと｜サーバーサイドでのフォームバリデーション

フォームアクセシビリティの向上のために、フォームの入力値を useActionState フックを使いバリデーションをする。

eslint

eslint-plugin-jsx-a11y プラグインをインストールするとアクセシビリティの問題を早期に検出できるようになる。pnpm lint コマンドで実行。

useActionState

  • useActionState フックを使うには、’use client’ をファイルの先頭に追加する。
  • (action, initialState) の2つの引数を取る。
  • [state, formAction] の2つの値を返す。
// create-form.tsx

'use client';
 
// ...
import { createInvoice, State } from '@/app/lib/actions';
import { useActionState } from 'react';

export default function Form({ customers }: { customers: CustomerField[] }) {
  const initialState: State = { message: null, errors: {} };
  const [state, formAction] = useActionState(createInvoice, initialState);
 
  return <form action={formAction}>...</form>;
}

Zod

Zodオブジェクトにそれぞれバリデーション用のメッセージを追加し、parse メソッドから safeParse メソッドに変更し success かチェックする。
parse は例外 Error throw する。safeParse はバリデーション結果をオブジェクト（success と data または error）で返す。

// actions.ts

export async function createInvoice(prevState: State, formData: FormData) {
  // Validate form fields using Zod
  const validatedFields = CreateInvoice.safeParse({
    customerId: formData.get('customerId'),
    amount: formData.get('amount'),
    status: formData.get('status'),
  });
 
  // 成功しなかった場合は早期に Zod のエラーメッセージを返す。
  if (!validatedFields.success) {
    return {
      errors: validatedFields.error.flatten().fieldErrors,
      message: 'Missing Fields. Failed to Create Invoice.',
    };
  }
 
  // ...
}

フォームコンポーネントの select と input に aria-describedby=”xxx-error” と、エラーを表示する HTML を追加する。

aria-describedby とエラーを表示する id は同じにして関係を確立する。

<form action={formAction}>
...
  <input
    id="amount"
    name="amount"
    type="number"
    step="0.01"
    placeholder="Enter USD amount"
    className="peer block w-full rounded-md border border-gray-200 py-2 pl-10 text-sm outline-2 placeholder:text-gray-500"
    aria-describedby="amount-error"
  />
  <div id="amount-error" aria-live="polite" aria-atomic="true">
    {state.errors?.amount &&
      state.errors.amount.map((error: string) => (
        <p className="mt-2 text-sm text-red-500" key={error}>
          {error}
        </p>
      ))}
  </div>
...
</form>

chapter 15 で学んだこと｜ログイン認証

ログイン認証のステップ

  • ユーザーが本人であることを確認すること。
  • 認証後にアプリケーションの使用を許可すること。

NextAuth.js

NextAuth.js はセッション管理、サインイン、サインアウトなどの複雑な要素を抽象化してくれる。
Next.js アプリケーションにおける認証の統合ソリューションを提供してくれる。

  • NextAuth.js をインストール
  • アプリケーションの秘密鍵を生成して、.env に AUTH_SECRET を設定

本番環境で認証を動作させるには Vercelプロジェクトの環境変数も更新する必要がある。

authConfig ページオプションを追加

auth.config.ts をプロジェクトルートに作成して、authConfig に NextAuth.js のオプションとページオプションを設定する。
ページオプションを使用するとカスタムしたサインイン、サインアウト、エラーページのルートを指定できる。

Next.js ミドルウェア

ルートを保護するロジックを auth.config.ts に追加。ユーザーがログインしていないとダッシュボードにアクセスできないようにする。

プロジェクトルートに middleware.ts を作成して、authConfig をインポートする。
ミドルウェアを使用する理由は、認証を検証するまで保護されたルートのレンダリングが開始されないことで、アプリケーションのセキュリティとパフォーマンを向上させるため。

auth.js

NextAuth() 設定して、認証に必要な機能(auth, signIn, signOut) を定義し使いやすくする。
その後、actions.ts で signIn をインポートして使う。

簡単なまとめ

  • auth.ts : 認証に必要な関数 (auth, signIn, signOut) を定義して使いやすくする
  • auth.config.ts : 認証設定（ログインページや認証チェックのルール）
    • signIn() : 実際にログイン処理をトリガー（内部で authorize() が呼ばれる）
    • Credentials() : 自前ログイン処理のロジック（ユーザー検索・パスワード照合など）
  • middleware.ts : ページアクセス時にログインしてるかどうかチェック

chapter 16 で学んだこと｜メタデータ

Next.js では2つのメタデータ追加方法がある。

  • Config-based : layout.js や page.js に、Metadata をインポートして、title や discripsion をオブジェクトとして記述する。
  • File-based : favion.ico や opengraph-image を app ディレクトリに配置。自動でタグが追加される。

以上、基本チュートリアル終了で、ここから先は Next Steps を参照する。

ページの先頭へ