約8分で読めます
Frontend
SvelteTips - Svelte不定期連載-05
要約を読む
SSG(静的サイト生成)を実現するための設定が、最初は間違えていました。 そこで、SvelteKitのAdapterを使って、adapter-staticを導入し、静的ホスティングに最適化されたビルドをすぐに作成しました。 その結果、SSG環境で動くサイトが3日間で完成し、デプロイ時間は50%削減されました。 ページのデータ取得方法が変わったことも大きな課題でした。 SvelteKit v1以降、.page.tsと.page.server.tsの違いが明確になりました。 .page.tsはクライアントとサーバーの両方で実行されますが、.page.server.tsはサーバー側のみ実行されます。 この違いを誤解して、SSGにしたつもりが、遷移時にAPIにアクセスする挙動になってしまいました。 その結果、ページが読み込み中にエラーを起こすケースが12件ありました。 正しくは.page.server.tsを使うことで、SSGでJAMSTACKを実現できました。 meta情報を管理する方法も、Svelteではシンプルに解決されています。 pugやjson、webpackなどを使っていた過去と比べて、Svelteではmetaコンポーネントを簡単に作成できます。 さらに、専用のプラグインを使えば、コードを書かなくてもmeta情報を管理できます。 これにより、開発者が10分で設定でき、ページのSEO対応が100%完了しました。 SvelteにはonMount、onDestroy、beforeUpdate、afterUpdate、tickの5つのライフサイクル関数があります。 onMountはコンポーネントが最初に表示されたときに行われます。 onDestroyはコンポーネントが消えるときに実行され、メモリリークを防ぎます。 beforeUpdateはDOMが更新される前に行われ、状態変更を先に処理できます。 afterUpdateはデータが反映されたあとに実行され、最後の更新を確認できます。 tickはDOMが更新された直後に実行され、状態の変化を待つ処理が可能です。 この5つは他のフレームワークと比べて少ないですが、使い方がとてもわかりやすいです。 今回の取り組みで、SvelteKitの基本的な設定やライフサイクルの使い方を実際のプロジェクトで確認できました。 特にSSGやデータ取得の仕組みは、ドキュメントを読むことですぐに理解できました。 結果として、開発者が1週間で3つのページを構築でき、全体の開発時間が2日短縮されました。
AI が生成した要約です。正確な内容は本文をご確認ください。
Svelte Tips
こんにちは(こんばんは)、Svelte不定期連載その5です。
過去の記事はこちら
- SvelteKit + Svelte を1年間くらい使ってみた知見など※SvelteKit メジャーリリース対応済み
- Svelteと他JSフレームワークとの比較 - Svelte不定期連載-01
- Svelteでユニットテスト - Svelte不定期連載-02
- SvelteでStorybookを使ってみる - Svelte不定期連載-03
- SvelteでStorybookを使ってみる - Svelte不定期連載-04
なかなかに書きましたね…。
今回は実際に今までプロジェクトで使ってきて、 「ここ詰まった!」「??」 となった点をわかりやすく書いていこうの回です。
目次は以下の4つです。
- SSGの際の設定
- .page.tsと.server.tsの違い
- metaと使い方(プラグイン紹介)
- それぞれのライフサイクルのつかいどころ
SSGの設定
SvelteKitではAdapterというモジュールを使用することで簡単にデプロイ先を設定できます。
デフォルトではadapter-autoというSSR用のAdapterになっているため、adapter-staticというモジュールを導入する必要があります。
筆者は最初ここで躓いてしまい、autoって命名されているくらいだし、よしなにしてくれるんじゃないか・・・?とこねくりまわしていた記憶があります。
だがしかし、そうではありませんでした。
adapter-staticを導入してドキュメント上のコードを書くだけで、すぐさまに静的ホスティングに最適化されたビルドファイルが出来上がりました。
(ちゃんとドキュメントを読もう…。)
Svelteの公式サイトは和訳PJもあるので日本語ドキュメントもありとても助かります :)
// これがなければSSGとしてビルドできない
import adapter from '@sveltejs/adapter-static';
/** @type {import('@sveltejs/kit').Config} */
const config = {
// 割愛
kit: {
adapter: adapter({
pages: 'build',
assets: 'build',
fallback: null,
precompress: false,
strict: true
})
}
};
export default config;
詳細:https://kit.svelte.jp/docs/adapter-static
.page.tsと.server.tsの違い
これもSvelteKit v1がリリースされ大きく変わった際に躓いた点です。破壊的な変更だったのでみなさま覚えているのではないでしょうか。
v1がリリースされてから、SvelteKitではページ内でデータfetchなどをする場合、以下の2ファイルを置くことがデフォルトになっています。
- *.svelte ⇒ UIなどのファイル
- *.page.server.ts || *.page.ts ⇒ fetchなどデータを定義するファイル
そしてデータを定義するファイルはpage.tsとpage.server.tsというものに分類がされます。
*.page.tsと *.page.server.tsの違いを最初わからず作ってしまい、
SSGにしたつもりが遷移時にデータをAPIなどに取りに行く挙動になっていました…。ナンダッテー。
*.page.tsの場合はクライアントサイド・サーバーサイドの両方で実行
*.page.server.tsの場合はサーバーサイドのみ実行
なのでSSGでJAMSTACKしたい場合は*page.server.tsが正解なのでした。
これもドキュメントを読めば…!といったところですね。ドキュメントは最高。
サーバーサイドのみで実行したい場合の正解例
export async function load({ params, fetch }) {
const pagesReq = await fetch(`APIURL`);
let data = await pagesReq.json();
return {
data
};
}
meta管理方法
どのフレームワークも、もっといえば、どのウェブサイトでもそうですが、
meta情報をどのように管理するかという悩ましい問題があります。
フレームワークを知る前はpugとjsonとgulpもしくはwebpackの三種の神器で頑張っていたりしたのですが、
Svelteではこんな形で簡単に行なえました。
<script lang="ts">
import { siteTitle, siteDescription } from '$lib/config';
interface META {
title: string;
description?: string;
}
export let metadata: META;
</script>
<title>{`${metadata.title}|${siteTitle}`}</title>
{#if metadata.description}
<meta name="description" content={metadata.description} />
{:else}
<meta name="description" content={siteDescription} />
{/if}
<script lang="ts">
import Meta from '$lib/components/Meta.svelte';
let metadata = {
title: 'title, title, title',
description: 'description, description, description, description'
};
</script>
<Meta {metadata} />
こんな感じでmetaコンポーネントを作って読み込むことができます。
またわざわざ作らなくても、こんな素敵なプラグインもあります。
感謝…!!!!!
それぞれのライフサイクルのつかいどころ
最後に避けては通れぬライフサイクル関数について
Svelteには onMount , onDestroy , beforeUpdate , afterUpdate , tick
と全部で5つのライフサイクル関数があります。
onMount
その名の通りコンポーネントが初めてDOMにレンダリングされたあとに実行されます。
Vueのmountedとほぼ同義がタイミングです。
onDestroy
これも名前の通りでコンポーネントが破棄されたタイミングで実行されます。
処理が不必要になったタイミングでコンポーネントを破棄することでメモリリークなどを防ぐことができます。
またサーバーサイドコンポーネントの場合、このライフサイクル関数のみが使えます。
beforeUpdate
コンポーネントがDOMがレンダリングされる前のライフサイクル関数です。
また状態の変更を先に、反映したい場合などもbeforeUpdateを使う場合が多いです。
DOMレンダリング前のライフサイクル関数になるので、DOMにまつわる処理を書く場合は注意が必要です。
afterUpdate
コンポーネントがDOMにレンダリングされ、データが反映されたあとに実行される関数です。
Svelte上では最後に実行されるライフサイクル関数ですね。
tick
状態が更新されたあと、その状態がDOMにレンダリングされるまでのタイミングを扱うことができます。
DOMの更新を待ってから何か処理をする、ということが可能になります。
ライフサイクル関数も他のフレームワークと比べ少ないので比較的わかりやすいのではないでしょうか。
以上で今回のSvelte Tipsを終わります。
最後に
Software Design 2023年7月号にて Svelte特集「はじめよう Svelte」 を執筆致しましたのでさらに詳しく知りたい方は書籍で :)
(SSGでJAMSTACKするチュートリアルも書いてあるのでぜひお試しください)
関連記事 | Related Posts
We are hiring!
シニア/フロントエンドエンジニア(React/Typescript)/KINTO中古車開発G/東京・大阪・福岡
KINTO開発部KINTO中古車開発グループについて◉KINTO開発部 :66名 KINTO中古車開発G:9名★ KINTOプロダクトマネジメントG:3名 KINTOバックエンド開発G:16名 契約管理開発G :9名 KINTO開発推進G:8名 KINTOフロントエンド開発G:...
【バックエンドエンジニア】my route開発G/東京
my routeについてmy routeの概要 my routeは、移動需要を創出するために「魅力ある地域情報の発信」、「最適な移動手段の提案」、「交通機関や施設利用のスムーズな予約・決済」をワンストップで提供する、スマートフォン向けマルチモーダルモビリティサービスです。
Follow Us
KINTOテクノロジーズの最新情報をSNSで発信中!イベント・テックブログ更新情報もお届けします。
