ライフサイクルフック
Nuxtはフックを使用してほぼすべての側面を拡張するための強力なフックシステムを提供します。
このフックシステムは unjs/hookable によって動作しています。
Nuxtフック(ビルド時)
これらのフックは Nuxtモジュール とビルドコンテキストで利用可能です。
nuxt.config.ts 内で
export default defineNuxtConfig({
hooks: {
close: () => { }
}
})
Nuxtモジュール内で
import { defineNuxtModule } from '@nuxt/kit'
export default defineNuxtModule({
setup (options, nuxt) {
nuxt.hook('close', async () => { })
}
})
こちらも参照 api > advanced > hooks#nuxt-hooks-build-time
アプリフック(ランタイム)
アプリフックは主に Nuxtプラグイン によってレンダリングライフサイクルにフックするために使用されますが、Vueのコンポーザブルでも使用できます。
export default defineNuxtPlugin((nuxtApp) => {
nuxtApp.hook('page:start', () => {
/* ここにコードを記述 */
})
})
サーバーフック(ランタイム)
これらのフックは サーバープラグイン によってNitroのランタイム動作にフックするために利用可能です。
export default defineNitroPlugin((nitroApp) => {
nitroApp.hooks.hook('render:html', (html, { event }) => {
console.log('render:html', html)
html.bodyAppend.push('<hr>カスタムプラグインによって追加されました')
})
nitroApp.hooks.hook('render:response', (response, { event }) => {
console.log('render:response', response)
})
})
追加のフック
イベントセクション でカスタムフックの作成について詳しく学ぶ。
tips
このセクションは公式ドキュメントの翻訳ではなく、本サイト独自の補足記事です。
Nuxtのフックシステムとは?〜開発効率と拡張性を高める強力な仕組み〜
Nuxtは多彩なフックシステムを備えており、これを活用することでアプリケーションの挙動を自在にカスタマイズできます。フックは特定のイベントやライフサイクルのタイミングで処理を差し込む仕組みで、モジュール開発やプラグイン作成、サーバーサイド処理の拡張など幅広い用途に対応します。
この仕組みを使うことで、コードの分散管理や再利用がしやすくなり、複雑な処理もシンプルに実装可能です。特に大規模プロジェクトや複数人開発では、フックを適切に使いこなすことが品質向上と保守性の向上に直結します。
まず結論:Nuxtフックのポイント
-
多層的なフック体系
ビルド時、ランタイム(アプリ)、サーバーサイドの3つのレイヤーでフックが用意されている -
柔軟な拡張性
モジュールやプラグイン、Nitroサーバーの動作に対して自由に処理を差し込める -
公式のhookableライブラリ採用
安定したイベント駆動モデルで非同期処理も扱いやすい -
実務での活用例が豊富
ロギング、カスタム処理の挿入、ビルドプロセスの制御など多様な用途に対応 -
注意点としてはSSR/CSRの違いやHydrationの影響を理解することが重要
いつ使うべき?使わない方がよいケースは?
使うべきケース
-
モジュールやプラグインの開発時
Nuxtの標準機能にない独自機能を追加したいとき -
ビルドプロセスのカスタマイズ
例えばビルド完了後にファイルを生成したり、特定の処理を挟みたい場合 -
サーバーサイドのレスポンスやレンダリング処理の拡張
NitroプラグインでHTMLの後処理やレスポンスの加工を行うとき -
アプリケーションのライフサイクルに合わせた処理の挿入
ページ遷移開始時や終了時など、ユーザー操作に連動した処理を実装したい場合
使わない方がよいケース
-
単純なUIロジックやコンポーネント内の状態管理
フックはあくまでライフサイクルやビルドの拡張用なので、Vueのリアクティブ機能やコンポーネントのメソッドで十分な場合は不要 -
過剰なフックの乱用
フックを多用しすぎると処理の追跡が難しくなり、保守性が低下するため注意 -
パフォーマンスにシビアな処理をフック内で重く実行する場合
特にサーバーサイドのレンダリング中に重い処理を入れるとレスポンス遅延の原因になる
実務でよくあるユースケースとサンプルコード
1. ビルド完了後に静的ファイルを生成する
ビルドが終わったタイミングで独自のファイルを生成したい場合に便利です。
export default defineNuxtConfig({
hooks: {
'build:done': () => {
console.log('ビルド完了!ここで静的ファイルを生成します。')
// 例: fs.writeFileSync('dist/custom.txt', 'ビルド完了しました')
}
}
})
2. ページ遷移開始時にロギングを行う
ユーザーのページ遷移を検知してログを残したり、アナリティクスに送信したい場合。
export default defineNuxtPlugin((nuxtApp) => {
nuxtApp.hook('page:start', (to) => {
console.log(`ページ遷移開始: ${to.fullPath}`)
})
})
3. NitroサーバープラグインでHTMLにカスタム要素を追加
サーバーサイドレンダリング後のHTMLに独自のタグやスクリプトを挿入したいとき。
export default defineNitroPlugin((nitroApp) => {
nitroApp.hooks.hook('render:html', (html) => {
html.bodyAppend.push('<div id="custom-footer">カスタムフッター</div>')
})
})
よくある落とし穴・注意点
SSRとCSRの違いに注意
フックはサーバーサイドとクライアントサイドの両方で動作するものがありますが、処理のタイミングや環境が異なるため、サーバー専用やクライアント専用の処理を混同しないようにしましょう。
Hydrationエラーの原因になることも
クライアント側でサーバーと異なるDOM操作や状態変更をフック内で行うと、Hydrationエラーが発生することがあります。特にHTMLの直接操作は慎重に。
パフォーマンスへの影響
重い処理をフック内で同期的に実行すると、ビルド時間やレスポンス速度に悪影響を及ぼします。可能な限り非同期処理にし、必要な処理だけに絞ることが重要です。
フックの多用によるコードの複雑化
フックは便利ですが、乱用すると処理の流れが追いにくくなります。ドキュメントやコメントを充実させ、役割ごとに整理して使いましょう。
まとめ
Nuxtのフックシステムは、ビルドからランタイム、サーバーサイドまで幅広いタイミングで処理を差し込める強力な拡張機構です。これを活用することで、標準機能では実現しづらいカスタマイズや自動化が可能になります。
ただし、SSR/CSRの違いやパフォーマンスへの影響を理解し、適切な場面で使うことが重要です。実務ではビルド後処理やページ遷移のフック、サーバーサイドのレスポンス加工などが代表的なユースケースです。
Nuxtの公式ドキュメントと合わせて本記事の内容を参考に、フックを効果的に使いこなして開発効率と品質を高めてください。
フックは非同期処理もサポートしているため、Promiseを返す関数を登録することで複雑な処理も安全に実装できます。
また、フック名は公式ドキュメントで随時更新されるため、最新情報の確認を忘れずに行いましょう。
※このページは Nuxt.js 公式ドキュメントの翻訳ページです。
公式ドキュメントの該当ページはこちら:
https://nuxt.com/docs/3.x/guide/going-further/hooks