プライベートでNuxt3を使って開発していますが、何となく使っているところがあるのでちゃんと理解するために調べたり動かしたりして理解を深めました。
nuxt-linkの挙動について
何となく内部のリンクはnuxt-linkを使っていましたが、改めて挙動について深掘りしてみました。
NuxtのSSRでは初回読み込み時はサーバー側でレンダリングされて返却されます。aタグで遷移した際もサーバー側でレンダリングされますが、nuxt-linkを使った場合は、APIからのデータフェッチなどサーバー側で実行されずにクライアントで実行されています。
そのため、nuxt-linkを使って遷移した先のページは同期的に生成されておらず、変数などちょっと遅れてシュッと入ってくる感じになっています。開発者ツールでnetworkタブを見てみてもnuxt-linkで遷移した時はクライアントサイドでAPIが呼び出されていることが確認できます。
まあたしかに内部リンクへの遷移は特にSEOを気にすることもないので、SSRしてサーバー側への負荷をかける必要がないのでしょう。
ちなみに調べてみるとnuxt-linkでto propsに外部リンクを指定することもでき、外部リンクの場合は通常のaタグのように動作するそうです。
そのため、特に内部リンクと外部リンクでタグを使い分ける必要はないみたいですね。
疑問と仮説
ただSSGでやっているとnuxt-linkで遷移すると一瞬画面が表示されてそのあと画面が真っ白になりました。
これは遷移後にCSRでAPIコールしており、Netlifyをホスティングサービスとして使っているとサーバーを用意していないためにエラーになっていると思われます。
ローカルでは問題ないのですが、ローカルはSSRモードで動いているからだと思われます。
aタグだと問題ないため、あくまでも仮説ですが、SSGの場合はuseFetchをサーバーのみにするかuseAsyncDataにキャッシュキーを指定してあげれば再度呼ばれることもなく正常に動作するのかもしれないと思いました。
追記
そもそもSSGでserverディレクトリを使うこと自体想定されていないのかもしれないです。
Webサーバー用意してないのにserverディレクトリ使ってAPIコールする構成自体を見直すべきかもと思いました。
pluginとmiddleware
pluguinとmiddlewareの挙動の違いとかも何となく使い分けていたので、改めて調べてみました。
pluguinはアプリケーションの初期化時に実行してくれるもので、アプリケーション全体で利用するものはここでまとめて定義します。ちなみにファイル名の前に数字を付けることで、pluginが登録される順序を制御できます。
middlewareはページ遷移にあたって行う共通処理を記述することができます。middlewareを利用することでページ間の移動、サイトへのアクセス時にページを表示する前に事前に設定していた処理を行うことができます。
どちらもデフォルトではサーバーサイド、クライアントサイド双方で実行されます。ファイル名にclientとかserverとかつけるとそれぞれのみで実行されます。
改めて調べるとそれぞれの挙動を理解できて、ちゃんと使い分けができそうです。
useFetchとuseAsyncData
どちらを使えばよいか適切なタイミングがいまいちよくわかってないので調べてみました。
結論から言うとuseFetchは、$fetchを使ったデータ取得に特化した useAsyncDataのラッパー関数なので、基本的にデータを取得するだかならuseFetchを使えば良さそうです。
ここでいう$fetchとはofetchライブラリのことで、これは様々な環境で使用できるFetchAPIです。axiosのようなものみたいです。
useAsyncDataはどうやって使うかというと、以下のように引数を2つ取ります。
1 2 3 4 | const { data, pending, error, refresh } = await useAsyncData( 'test', () => $fetch('https://example.com/test') ) |
第1引数はキーを指定し、内部でキャッシュを保持しています。それによって2回目以降はAPIにリクエストをすることなく、前と同じ結果を返してくれます。このキャッシュはNuxt内部で保持するため、キャッシュを区別するための一意なキーが必要となります。
第2引数は非同期処理を行う関数を指定しています。
useAsyncDataの第二引数が() => $fetchになるのであれば基本的にuseFetchを使用すれば問題なさそうです。