ランタイム設定
Nuxt Kit は、Nuxt ランタイム設定にアクセスし、変更するためのユーティリティを提供します。
useRuntimeConfig
ビルド時に、解決された Nuxt のランタイム設定にアクセスすることが可能です。
型
function useRuntimeConfig (): Record<string, unknown>
updateRuntimeConfig
ランタイム設定を更新することも可能です。これは既存のランタイム設定とマージされ、Nitro がすでに初期化されている場合は、Nitro ランタイム設定をリロードするための HMR イベントをトリガーします。
型
function updateRuntimeConfig (config: Record<string, unknown>): void | Promise<void>
tips
このセクションは公式ドキュメントの翻訳ではなく、本サイト独自の補足記事です。
はじめに:ランタイム設定がもたらす利便性と課題解決
Nuxtアプリケーションの開発において、環境ごとに異なる設定を柔軟に扱うことは非常に重要です。ビルド時に決まる設定だけでなく、実行時に動的に設定を読み込んだり更新したりできることは、開発効率や運用の柔軟性を大きく向上させます。
Nuxtのランタイム設定機能は、こうしたニーズに応えるために用意されています。useRuntimeConfigを使えば現在の設定値を簡単に取得でき、updateRuntimeConfigを使えば実行中に設定を変更し、必要に応じて即座に反映させることも可能です。
しかし、これらの機能を正しく理解しないと、意図しない挙動やパフォーマンス低下を招くこともあります。本記事では、Nuxtのランタイム設定の基本から実務での活用例、注意すべきポイントまで丁寧に解説します。
まず結論:Nuxtランタイム設定の要点まとめ
useRuntimeConfigでビルド後のランタイム設定を安全に取得できるupdateRuntimeConfigで実行中に設定を動的に更新可能(NitroのHMRもトリガー)- 設定はサーバー・クライアント両方で利用可能だが、公開設定と非公開設定を区別することが重要
- 動的更新は主に開発時や特定の管理画面での設定変更に有効
- SSRやHydrationのタイミングに注意しないと、クライアントとサーバーで設定がずれるリスクがある
いつ使うべきか?使わない方がよいケースは?
使うべきケース
-
環境ごとに異なるAPIエンドポイントやキーを切り替えたいとき
例:開発・ステージング・本番環境でAPIのURLを変える場合など。 -
ユーザーの操作や管理画面から設定を動的に変更したいとき
例:管理者が管理画面で機能フラグを切り替え、即時反映させたい場合。 -
ビルド時に決められない設定を実行時に読み込みたいとき
例:外部サービスのトークンや動的に変わる設定値。
使わない方がよいケース
-
頻繁に変更される大量の設定を管理したい場合
ランタイム設定はあくまで軽量な設定管理向け。大量のデータや頻繁な更新は別の状態管理やAPIで行うべき。 -
クライアント側だけで完結する設定をサーバー経由で管理しようとする場合
クライアント専用の状態管理(VuexやPiniaなど)を使うほうが効率的。 -
SSRのHydration時に設定の不整合が起きやすいケース
サーバーとクライアントで設定が異なるとUIの不整合や警告が発生するため、設定の同期に注意が必要。
実務でよくあるユースケースとサンプルコード
1. 環境ごとのAPIエンドポイント切り替え
const config = useRuntimeConfig()
const apiBaseUrl = config.public.apiBaseUrl
nuxt.config.tsで環境ごとにpublic.apiBaseUrlを設定し、コンポーネントやComposableで取得してAPI呼び出しに利用します。
2. 管理画面からの機能フラグ切り替え
管理画面でupdateRuntimeConfigを使い、機能フラグを動的に切り替えます。
await updateRuntimeConfig({
public: {
featureXEnabled: true
}
})
これにより、NitroのHMRがトリガーされ、即座に設定が反映されます。
3. 外部サービスのトークンを実行時に差し替え
const config = useRuntimeConfig()
const token = config.apiToken
トークンはビルド時に決められない場合が多いため、実行時に環境変数や管理画面から設定し、useRuntimeConfigで取得します。
よくある落とし穴・注意点
SSRとCSRでの設定の不整合
サーバーサイドレンダリング(SSR)時に取得した設定と、クライアントサイドでの設定が異なると、HydrationエラーやUIの不整合が発生します。特にpublic設定はクライアントにも公開されるため、両者で同じ値を保証することが重要です。
パフォーマンスへの影響
updateRuntimeConfigはNitroのHMRをトリガーするため、頻繁に呼び出すとパフォーマンスに悪影響を及ぼします。動的更新は必要最低限に留め、頻繁な変更が必要な場合は別の仕組みを検討しましょう。
セキュリティ面の配慮
非公開の設定値(APIキーやシークレットなど)はruntimeConfigのprivate側に配置し、クライアントに漏れないように管理してください。publicに含めるとクライアントに丸見えになるため注意が必要です。
まとめ
Nuxtのランタイム設定は、環境ごとの設定管理や実行時の動的な設定変更を可能にし、開発と運用の柔軟性を大きく高めます。useRuntimeConfigとupdateRuntimeConfigを適切に使い分けることで、環境依存の設定や管理画面からの即時反映など多様なニーズに対応可能です。
ただし、SSRとCSR間の設定の整合性やパフォーマンス、セキュリティ面には十分注意し、ユースケースに応じて使い分けることが重要です。これらを理解し活用することで、Nuxtアプリケーションの品質と開発効率をさらに向上させましょう。
※このページは Nuxt.js 公式ドキュメントの翻訳ページです。
公式ドキュメントの該当ページはこちら:
https://nuxt.com/docs/3.x/api/kit/runtime-config