🚪

【SvelteKit 入門】はじめに

に公開

React Vue.js に対し後発である Svelte ですが、2022年あたりから整備が加速し安定感が出てきました。同時に、公式(?)フレームワークである SvelteKit も良い仕上がりを見せており Next.js Nuxt.js に対し遜色無いレベルまで到達したと言っても差し支えありません。

実務で十分使える品質まで来ているので、あとは参考情報の蓄積ぐらいですね。
(それが一番ネックでは・・・)

そんな SvelteKit を触ってみようかなと思った方々の参考になればというシリーズです。


シリーズまとめ(随時追加・更新)

【SvelteKit 入門】はじめに now reading
【SvelteKit 入門】作業の前に
【SvelteKit 入門】アダプター設定・ホスティング・コンテナ運用
【SvelteKit 入門】ルーティング
【SvelteKit 入門】データハンドリング(+page.js)
SvelteKit + microCMS でブログ構築

SvelteKit って何

Svelteという記法をベースに、サイト・アプリケーション制作に必要なルーティング・レンダリング制御等の機能をまとめたフレームワーク。フロントエンドを名乗ってはいるが、それなりにバックエンドも実装可能。

  • 少ない記述、軽量なファイルサイズ、高速な動作
  • JSXを使わないため、ほぼ素のHTML/CSS で書ける
  • UI・機能ごとに切り出し、ファイル単位でコンポーネント化

Svelteの強みをフル活用しつつ、アプリケーション化するのに必要な機能が用意された環境が手に入る。シンプルなWEBサイトから多機能なWEBアプリケーションまで対応可能。

また、他のFWにありがちな 「FWを採用している時点である程度のファイルサイズになる」 といったことが無い。なので

「FWのこの機能だけ使いたいけど・・・そのためにわざわざ太らせるのもなぁ・・・」

という人もSvelteKitを使えば解決。

Svelte・SvelteKit の現状

  • 開発元が色々と模索する段階は終了(=基本仕様の変更はもうあまり起きない)
  • 今後は本体・エコシステム共に改善・拡大がメインとなっていくと思われる
  • バージョン毎の軽量化に余念が無い(ちょっとやりすぎ)
  • ネットや書籍の二次情報も少しずつ増加傾向
  • IaaS等がチュートリアルにSvelte SvelteKitを入れるぐらいには存在感が出てきた
  • ようやく 実務使用を想定した人にもおすすめできる 段階に来たと言える

ユーザーから見ても、ここ最近で色々と整った感が強め。
「今までゴミ袋に埋もれながら開発に没頭してきたけど、一段落したから部屋キレイにしたよ!」 という印象。

(開発元も「公式ページやチュートリアルをオーバーホールした」と言っているあたり、自覚がある様子)

おおまかな仕様・機能

■ 基本

  • 共通レイアウト(ヘッダーやメニュー)はファイルを配置するだけ
    • 適用範囲の柔軟な制御も可能
  • ルーティングはディレクトリベース

■ レンダリング関連

  • SSR(サーバー),CSR(クライアント)どちらも対応
  • ちなみにデフォルトでは、SSRとCSRを混ぜた hydration
  • prerendering(=SSG)も可能
  • SPAとして出力することもできる

■ アプリケーション視点

  • TypeScript ネイティブ対応
  • 状態管理に使えるstoreがデフォルトで組み込み済(更新検知つきで)
  • ルーティング先にページではなくハンドラ的なjsファイルを置くことで、エンドポイントも作れる
  • 全ての通信に処理を挟む(ミドルウェアっぽい)事もでき、認証等で使用可能

参考情報の陣形

公式

■ Svelte   公式(英語)   日本語版
 ├ Docs (辞書的に利用)
 ├ Tutorial (下記参照)
 ├ Example (少しハイレベルな使用例もあり)
 └ REPL (ブラウザエディタ)

■ SvelteKit   公式(英語)   日本語版
 ├ Docs (辞書的に利用)
 ├ Tutorial (下記参照)
 └ StackBlitz (ブラウザエディタ)

■ learn.svelte.dev   公式(英語)   日本語版
 Svelte・SvelteKit どちらも扱っている 公式によるほぼ最強のチュートリアル
 Svelte の基本/応用・SvelteKit の基本/応用、4パートでわかりやすく実践

コミュニティ(2つ紹介)

Svelte SvelteKitプロジェクトで使えるnpmパッケージや、SvelteKit製のWEBサイト等(※大量)を集めたサイト

Made with Svelte
Best of Svelte

トップページは「Svelteでこんなサイト・プロジェクト作ったよ!」というものなのでスルー。サイト内を漁ればSvelteでインポートして使えるコンポーネント等が見つかると思うので、使うなり参考にするなり活用。

技術ブログ等の二次情報について

できるだけ 2023年以降 の情報を参考にするのが○。特にSvelteKitは。
それ以前は現在の仕様と異なる点が散在し、使える部分とそうでない部分の判別が難しい。参考にするとしても全体の設計やアイディアのみにとどめ、コピペ実装は避けるのが賢明。

おすすめのステップアップ

JavaScriptのフレームワークに慣れている人には当たり前の話ですが…

Svelteが担うのはあくまで1つ1つの画面(とその中のロジック)です。それらを組み合わせ、複数の画面を行き来する1つのアプリケーションとしてサーバー上で稼働し、ユーザーアクセスを受けられる状態にするには、SvelteKit等のハコに入れる必要があります。その全体像をイメージしつつ色々といじってみるのが良いかと思います。

1. Svelte の概要把握【Svelte 自体が初めての人】

公式チュートリアル Part1。
ブラウザ上で完結しているので環境構築は不要。
(オレンジの solve → を押すのを忘れずに)

2. SvelteKit をいじる

公式チュートリアル Part3。
ここで SvelteKit の機能が順番に解説されていくので、消化していく過程でさっき見た Part1 の記述も色々やってみるとダブルで試せてgood。

3. ローカルでプロジェクト立ち上げ

ここまでで「結構ええやん」となった人は、そろそろブラウザから脱出。
SvelteKit公式トップ で紹介されてるコマンドに従えば、ローカル環境でリアルタイムプレビューしながらコーディングが可能。またチュートリアルではコード編集のみでしたが、これでファイル構成も自由にいじれるように。

4. 気になる部分を掘り下げ

Svelte に関しては チュートリアル Part2
SvelteKit に関しては チュートリアル Part4
がそれぞれ "Advanced" となっていますが、難易度が高いわけではなく用途が実務寄りというだけです。一回やってみて「ああ、こういう機能をこういう記述で書けるのね」と軽く認識だけしておけば良いかと。
また、網羅的に把握しておきたい場合はドキュメントに目を通すのもあり。

【補足】ルーティングについて

以前の SvelteKit はファイルベース・デイレクトリベース どちらにも対応していた ので、エンジニアが好きなように構成していました。やろうと思えばページ数 = ファイル数(routes内)にも出来たということですね。

プロジェクト/
    ...
     ├ routes/
     │   ├ index.svelte       <- /
     │   ├ movies.svelte      <- ファイル名がそのままURL対応
     │   └ pictures/
     │       └ index.svelte   <- ディレクトリ名 + index という構成も可能
     ├ ...
    ...

しかし上記ルーティングは廃止され、今はディレクトリベース のみ になりました。
直後は反対意見もそれなりに出てましたね…笑

プロジェクト/
    ...
     ├ routes/
     │   ├ +page.svelte         <- インデックスファイル名はまさかの頭文字「+」
     │   ├ movies/              <- URLに対応させるディレクトリを作り
     │   │   └ +page.svelte     <- インデックスファイルを配置
     │   └ pictures/
     │       ├ +page.js         <- データ処理のファイルも置ける
     │       └ +page.svelte
     ├ ...
    ...

以前の仕様のように 同じ挙動をさせる手法がいくつも存在する というのは、柔軟性がある とプラスに捉えることもできますし、ベストプラクティスがブレる といったマイナスの捉え方をすることもできます。この変更は正しい・正しくないというよりは好き嫌いの話ですね。

これを回避するためにsvelte + ルーティングのパッケージ という構成も可能ですが、よほど嫌でなければ わざわざ SvelteKit 以外の構成にする必要性は低い かと思います。

Discussion