SCSKの畑です。
今回は完全に Nuxt3 に閉じた話題ですが、アプリケーションのルーティングパス設計を当初の意図通りのものにするのにちょっと苦労したので、その経緯と解決策もといちょっとした Tips について紹介してみます。タイトルの通り完全に小ネタです。。。
本題
これまでのエントリで取り上げてきた Redshift テーブルデータのメンテナンスアプリケーションにおいては、テーブルの主な編集状態(ステータス)が以下3種類定義されており、設計上それぞれで画面(URL パス)を分けています。
- normal:通常状態
- editing_content:テーブルデータの編集中
- awaiting_approval:編集後のテーブルデータ更新承認待ち
- 以前のエントリで記載したような更新承認用の簡易ワークフローに対応
上記の各画面に対応した機能が各テーブルで共通であることから、実装及びメンテナンスコストを抑えるために各テーブルごとにページ/コンポーネントは作成せず、共通化する方針としていました。よって、テーブル名については URL パスからパラメータとしてページ/コンポーネントに渡してあげるような形で、以下のような URL パス設計を考えていました。対象テーブルのステータスが normal であればテーブル名のみ、そうでなければ対象のステータスがその後ろの URL で指定されるような形式です。
- <ルートURL>/mastertable/<テーブル名>:通常状態の画面
- <ルートURL>/mastertable/<テーブル名>/editing_content:テーブルデータの編集中画面
- <ルートURL>/mastertable/<テーブル名>/awaiting_approval:テーブルデータ更新承認待ち画面
Nuxt3 の場合はデフォルトでファイルシステムベースのルーティングが使われており、pages ディレクトリ配下のファイル/ディレクトリ配置に応じてルーティングが定義されます。また、パスの一部をパラメータとしてページ/コンポーネントに渡すような動的ルーティングも可能となっており、ファイル/ディレクトリ名の一部を [] で囲むと、その部分がパラメータとして解釈されます。先述の通り、今回の場合はテーブル名を [table_name] としてパラメータとして渡すことを考えて、ファイル/ディレクトリ構造を以下のようにしていました。
pages/mastertable ├ [table_name].vue:通常状態の画面 └ [table_name] ├ editing_content.vue:テーブルデータの編集中画面 └ awaiting_approval.vue:テーブルデータ更新承認待ち画面
ところが、この方法だと上手くいきませんでした。[table_name] の定義が同じディレクトリ階層で重複してしまったことが原因と考えられますが、ちょっと調べた限りでは他の方法が見当たらず。
この時点では各機能の開発中であったため以下のような仮のルーティングに変更して作業を進めていたのですが、URL パスの末尾にテーブル名が来てしまい当初の設計通りになっていない上、各画面の Vue ファイル名が同一になってしまう分かりづらさなども相まって、事あるごとに何とかならないかとモヤモヤすることに。
pages/mastertable ├ [table_name].vue:通常状態の画面 ├ editing_content └ [table_name].vue:テーブルデータの編集中画面 └ awaiting_approval └ [table_name].vue:テーブルデータ更新承認待ち画面
その後開発が進み、テーブルデータのバージョン管理(参照)機能を追加したのですが、バージョン情報を URL パスとしてどう取り扱うかを検討する必要がありました。同機能においても画面としては通常状態のものを共用する想定であり、バージョン情報を URL パスとして渡すかどうかで画面上に表示するデータの種類(最新データ or 指定バージョンのデータ)を切り替えるようなイメージで考えていました。
それと合わせて先述したルーティングの課題についても検討すべく色々調べた結果どうにか解決策に辿り着き、最終的には以下のようなディレクトリ構成となりました。
pages/mastertable └ [table_name] ├ [[version_index]].vue:通常状態(最新データ)の画面 兼 特定のバージョンデータ参照画面 ├ editing_content.vue:テーブルデータの編集中画面 └ awaiting_approval.vue:テーブルデータ更新承認待ち画面
version_index というバージョン情報を表すルートパラメータを [[]] で囲んでいますが、この記法が解決策のキモでして、オプショナル(省略可能)なルートパラメータという意味合いとなります。
即ち、URL パスに version_index ルートパラメータを含むか否かで画面に表示するデータの種類の出し分けを行うロジックを実装できる上、URL パスとしても
- <ルートURL>/mastertable/<テーブル名>:通常状態(最新データ)の画面
- <ルートURL>/mastertable/<テーブル名>/<バージョン情報>:特定のバージョンデータ参照画面
- <ルートURL>/mastertable/<テーブル名>/editing_content:テーブルデータの編集中画面
- <ルートURL>/mastertable/<テーブル名>/awaiting_approval:テーブルデータ更新承認待ち画面
のように、通常状態(最新データ)に対応する URL パスはバージョン番号が省略された結果テーブル名のみの形式となり、編集中/承認待ちの場合はテーブル名の後ろに対応するステータス名が指定される形式となります。よって、バージョン情報の取り込みと共に当初の設計通りの URL パスを指定することができ、無事にモヤモヤ感も解消することができました。。
ちなみに、Nuxt3 ではカスタムルーティングを実装することも可能ですが、本案件事例ではそこまでの必要性がなかったため本記事では触れません。そのあたりも含めたルーティング設定の詳細については以下のサイト様がよくまとまっているかと思いました。

まとめ
Nuxt3 における動的ルーティングについては色々な情報があるのですが、オプショナルなパラメータの使用例も含めた情報はそれほど多くないように思えたため、備忘がてら書いてみた次第です。
本記事がどなたかの役に立てば幸いです。