Svelte に関するメモ
雪猫
※ REPL は svelte.dev でしか利用できません
雪猫入門
チュートリアルが充実しているので一通りやるとよさそう。
実際にコードを試したいときは REPL にてオンラインで動かすことができます。
メリット
- チュートリアルが充実してる
- コンポーネント単位でコードや CSS を書ける
- 素の CSS で十分（学習コストが低い）
- 素の JS っぽく書ける（学習コストが低い）
- ストア機能がある（Vuex, Pinia 相当）
- ストアを含めた Reactivity が便利
- *.svelte では async/await よりこちらを活かせる書き方をする
-
<head>を動的に書き換えられる（Vue にはなかった） - Vercel, Cloudflare Pages へのデプロイが簡単
- ブラウザで GitHub 連携するだけ
- PR 作成時にプレビュー環境へ自動デプロイ
デメリット
- ライブラリ等のエコシステムがまだ充実していない
- SvelteKit だとルーティングでエイリアスが張れない？（ファイルパスベースのため）
- クライアントに初期化用のフックがない
- サーバーにはあるので一般的なログイン処理は書けそう
-
bind:thisで HTML Element やコンポーネントをバインドすると未定義 (undefined) な瞬間がある- 厳密に型を定義する場合
Element | undefinedとして?.でメソッドを呼び出す必要がある - 単に
Elementにしてしまってもさほど実害はなさそう
- 厳密に型を定義する場合
-
onMount,afterNavigate以外の箇所ではサーバーとクライアント両方で実行されてしまうのでクライアントだけで行いたい処理はif (browser) {}で囲う必要がある- import も動的に行う必要がある
const { ClientOnly } = await import('client-only');
- import も動的に行う必要がある
雪猫コンポーネント
機能単位で *.svelte コンポーネントを作成できる。
ViewModel + View という印象。コアロジックは lib/*.ts に書いた方がよさそう。
コンポーネント間で情報を受け渡しする方法
- 親コンポーネントから子コンポーネントへ一方通行なら Context API
-
lib/*.tsで変数をexport - 購読をしたいなら ストア
複数のページで使われるものは libs/components/*.svelte に置く。
単一のページでしか使われないコンポーネントは routes/*.svelte に置いてもいい。
export
export function
ルーティング
**/+page.svelte のファイルパスがそのままルーティングになる。
エイリアスは張れなさそう？今のところ +page.svelte だけ複数置いて中身をコンポーネントにしてる。
レンダリングの前に処理をしたい場合は +page.ts や +layout.ts で処理して +page.svelte や +layout.svelte にて export let data: PageData; // or LayoutData で受け取る。
ライブラリ作成
ライフサイクル
雪猫Server or Client
Client
onMount や afterNavigate 内の処理はクライアントとしてレンダリングされるので window プロパティ等が使用できる。
if (browser) でもクライアント用の処理を書ける。
雪猫Logic
lib/**.ts に書く。import { ClassName } from '$lib/ClassName で読み込み。
ストアの置き場所はどこが適切？
→ 各クラスと同居させるか lib/stores/*.ts に置くのが良さそう。stores/*.ts に置いてしまうとディレクトリを移動した際に自動で修正してもらえない。
雪猫補完機能の実装
XSS 脆弱性がありそうなのでサニタイズちゃんとやった方がよさそう。
インポート
onMount(async () => {
const { default: Tribute } = await import('tributejs');
});
サンプルコード
雪猫Service Worker
-
$libで参照できなさそう？-
./libは使える
-
雪猫CSS
動的に CSS を変更したい
クラスを切り替える。
コンポーネントをまたいだ CSS を定義したい
雪猫デプロイ
Vercel
動かないときのチェックリスト
-
リモートリポジトリに変更が反映されている
- プッシュしている
- コミットしている
-
ローカル
npm run devで動く -
ローカル
npm run build && npm run previewで動く - プラットフォームの障害がないか
- 再デプロイ
雪猫PWA
要件は以下の 4 点。
- HTTPS
- アイコン
- Service Worker
- マニフェストファイル
最低限の設定
HTTPS
現代の Web サイトでは当然なので割愛します。
アイコン
144x144 以上の PNG（SVG だとうまく表示されなさそう？）を用意して static ディレクトリに置きます。
ファイル名は任意で構いません。マニフェストファイルで指定します。
static/icon.png に置いたものとします。
Service Worker
空の src/service-worker.js を作成します。
マニフェストファイル
<link rel="manifest" href="%sveltekit.assets%/manifest.webmanifest" />
{
"name": "<your_app_name>",
"short_name": "<your_app_name>",
"start_url": ".",
"display": "standalone",
"background_color": "#fff",
"icons": [
{
"src": "icon.png",
"sizes": "144x144",
"type": "image/png"
}
]
}
動作確認
トラブルシューティングには Lighthouse が便利です。
Chrome であればデベロッパーツール (F12) の Lighthouse タブから利用できます。
プラグイン
プラグインもありマニフェストファイル等を生成したりできるようですが結局アイコンを用意したりマニフェストファイルの設定を書いたりしないといけないのであまり有用性が分かりませんでした。
細かい設定をするのには便利なのかもしれません。
雪猫OGP
自サイトの画像生成
他サイトの CORS 回避
雪猫UI
仮想リスト