はじめに
Next.jsやNuxtなど多くフレームワークがファイルベースルーティングを採用しています。SvelteKitもファイルベースルーティングを採用していますが、独自のアプローチとして、+page.svelteや+layout.svelteのように、ルーティング関連のファイルには必ず+のプレフィックスを付けるというルールを持っています。この命名規則は、初めてSvelteKitを利用する人にとっては少し違和感を持たれるかもしれません。この記事では、なぜSvelteKitがこの形式を採用しているのかについて説明していきます。
+プレフィックスを採用する前のファイルベースルーティングの弱点
ルーティングの設定に複数の方法が存在していた
+プレフィックスを採用する前はsrc/routes/foo.svelteまたはsrc/routes/foo/index.svelteとルーティングファイルを定義する方法が2つありました。
Svelteの設計思想の「1つのことを実現できる方法は1つであるべきである」という考えに反していましたので1つの方法になりました。
これはとてもいい変更で２つの方法があることで混在してしまう可能性がありますし、特にチーム開発では混乱が生じます。
回避策を講じないと関連するファイルを同じ場所に配置することができなかった
foo.svelteに関連するファイルを同じ場所に配置したい場合があると思いますが、その場合に少し面倒でした。
_item.svelteや_components/item.svelteなど回避策を講じた命名にしないといけません。
+プレフィックスを採用したことでsrc/routes/foo/+page.svelte、src/routes/foo/components/item.svelteまたはsrc/routes/foo/item.svelteのように関連するファイルを同じ場所に配置することができます。
エディタ上でルートファイルを探しづらかった
エディタではアルファベット順にグループ化されています。
src/routes/foo.svelteやsrc/routes/foo/index.svelteがルーティングの場合はどれがルーティングファイルなのかぱっと見ではわかりづらいです。しかし、+プレフィックスを採用したことで子ディレクトリ、ルーティングファイル、通常のファイルの順序で見られるようになりました。
src/
└─── routes/
├── about/
│ ├── +page.svelte
│ └── item.svelte
├── contact/
│ └── +page.svelte
├── +layout.svelte
└── +page.svelte
また、コマンドパレットに+pageを入力するだけですべてのルートのリストを表示でき、blog+などを入力すると該当ルーティングのファイルをすぐに探すことができます。
将来の拡張性が悪かった
SvelteKitが今後成長していく中で新しい機能を追加することがあると思いますが、互換性を保ったまま追加するのが難しかったです。しかし、+プレフィックスを採用したことで予約済みのプレフィックスができましたので例えば+loading.svelteのような機能が追加された場合も破壊的変更を少なく導入することができます。
おわりに
SvelteKitの+プレフィックスは、最初は違和感を持たれるかもしれません。しかし、このルールはファイルの管理をスムーズにしてくれて、エディタでファイルを見つけやすくしてくれます。さらに、新しい機能の追加もやりやすくなるので将来の破壊的変更を最小限に抑えることができます。
他のフレームワークでは採用していないものなので違和感を持った方々の疑問に少しでもこの記事が答えられていると嬉しいです。
僕も最初はとても違和感がありましたが、今はすごく合理的でいいルーティングシステムだと感じています。
参考