brand logo

ドキュメント

reloadNuxtApp

reloadNuxtApp はページのハードリロードを実行します。

reloadNuxtApp はアプリをハードリロードし、ページとその依存関係をサーバーから再リクエストします。

デフォルトでは、アプリの現在の stateuseState でアクセスできる状態)も保存されます。

こちらも参照 guide > going-further > experimental-features#restorestate

reloadNuxtApp(options?: ReloadNuxtAppOptions)

interface ReloadNuxtAppOptions {
  ttl?: number
  force?: boolean
  path?: string
  persistState?: boolean
}

options (オプション)

: ReloadNuxtAppOptions

以下のプロパティを受け入れるオブジェクトです:

  • path (オプション)

    : string

    デフォルト: window.location.pathname

    リロードするパス(デフォルトは現在のパス)。これが現在のウィンドウの場所と異なる場合、ナビゲーションがトリガーされ、ブラウザの履歴にエントリが追加されます。

  • ttl (オプション)

    : number

    デフォルト: 10000

    将来のリロードリクエストを無視するミリ秒数。この期間内に再度呼び出された場合、reloadNuxtApp はリロードループを避けるためにアプリをリロードしません。

  • force (オプション)

    : boolean

    デフォルト: false

    このオプションはリロードループ保護を完全にバイパスし、以前に指定された TTL 内でリロードが発生した場合でもリロードを強制します。

  • persistState (オプション)

    : boolean

    デフォルト: false

    現在の Nuxt 状態を sessionStorage にダンプするかどうか(nuxt:reload:state として)。デフォルトでは、experimental.restoreState が設定されている場合や、状態の復元を自分で処理しない限り、リロードには影響しません。

tips

このセクションは公式ドキュメントの翻訳ではなく、本サイト独自の補足記事です。

reloadNuxtApp の概要とメリット

Nuxt アプリケーションの開発において、ページの状態をリセットしたり、サーバーから最新のデータを強制的に取得したい場面は少なくありません。reloadNuxtApp は、そんなときに役立つ関数で、ブラウザの通常のリロード(ハードリロード)をプログラム的に実行します。

この機能を使うことで、単なるページ遷移では解決できない状態のリセットや、キャッシュされたデータのクリア、サーバー側の最新状態の反映を確実に行えます。特に、状態管理やクライアントサイドのキャッシュが複雑なアプリケーションで重宝します。


まず結論:reloadNuxtApp のポイント

  • ハードリロードをプログラムから実行し、ページと依存リソースをサーバーから再取得できる
  • 現在の Nuxt 状態を sessionStorage に保存し、リロード後に状態を復元することも可能(実験的機能)
  • リロードの連続実行を防ぐ TTL(有効期限)機能でリロードループを回避できる
  • リロード先のパスを指定可能で、別ページへのリロードも制御できる
  • force オプションでリロードループ保護を無効化し、強制的にリロードを実行できる

いつ使うべきか?使わない方がよいケース

使うべきケース

  • 状態が複雑に絡み合い、単純なリセットが困難なとき
    例:Vuex や Pinia の状態が不整合になった場合や、useState の状態が複雑に変化している場合に、確実に初期状態に戻したいとき。

  • サーバー側の最新データを強制的に取得したいとき
    クライアントキャッシュや API キャッシュが影響して最新情報が反映されない場合に有効。

  • ページ遷移ではなく、完全なリロードが必要な UI 操作があるとき
    例えば、ユーザーが設定変更後に全体の状態をリセットしたい場合など。

使わない方がよいケース

  • 単純なページ遷移や部分的な状態更新で済む場合
    例えば、通常のルーティングや状態管理の更新だけで問題が解決するなら、リロードは過剰。

  • パフォーマンスが重要なリアルタイムアプリケーション
    ハードリロードはページ全体の再読み込みを伴うため、ユーザー体験を損なう可能性がある。

  • 状態の復元を自前で管理していない場合
    persistState を使って状態を保存しないと、リロード後に状態が失われるため注意が必要。


実務でよくあるユースケースとサンプルコード

1. ユーザー設定変更後の完全リセット

ユーザーがテーマや言語設定を変更した際に、アプリ全体をリロードして反映させたい場合。

import { reloadNuxtApp } from '#app'

function onUserSettingsChange() {
  reloadNuxtApp({
    persistState: true, // 状態を保存して復元したい場合
  })
}

2. API の大幅な更新後に最新データを取得

API の仕様変更やデータ構造の変更があり、クライアント側のキャッシュをクリアして最新状態を取得したいとき。

reloadNuxtApp({
  force: true, // 強制リロードでキャッシュを完全にクリア
})

3. 特定のパスへリロードしてナビゲーションも行う

現在のページとは異なるパスにリロードしつつ、ブラウザ履歴にも残したい場合。

reloadNuxtApp({
  path: '/dashboard',
})

よくある落とし穴・注意点

SSR と CSR の違いによる影響

reloadNuxtApp はブラウザのハードリロードを行うため、サーバーサイドレンダリング(SSR)とクライアントサイドレンダリング(CSR)の両方が再実行されます。これにより、サーバー側の初期化処理やミドルウェアも再度走るため、想定外の副作用が起きることがあります。

Hydration エラーに注意

リロード後に状態を復元する際、サーバーからの HTML とクライアントの状態が不整合になると Hydration エラーが発生することがあります。特に persistState を使う場合は、状態の整合性を保つための実装が必要です。

パフォーマンスへの影響

ハードリロードはページ全体の再読み込みを伴うため、ユーザー体験が一時的に低下します。頻繁に呼び出すのは避け、必要な場合に限定して使うことが望ましいです。

リロードループの防止

ttl オプションにより、一定時間内の連続リロードを防止しますが、force を使うとこの保護を無効化します。誤って無限リロードループを作らないよう注意してください。


まとめ

reloadNuxtApp は Nuxt アプリの状態を強制的にリセットし、最新のサーバー状態を反映させたいときに非常に便利な関数です。状態の復元やリロード制御のオプションも充実しており、複雑な状態管理を扱う実務で役立ちます。

ただし、ハードリロードはユーザー体験やパフォーマンスに影響を与えるため、使うべき場面を見極めることが重要です。状態の復元やリロードループ防止の仕組みを理解し、適切に活用しましょう。