KINTO Tech Blog
Development

SvelteTips - Svelte不定期連載-05

Cover Image for SvelteTips - Svelte不定期連載-05

Svelte Tips

こんにちは(こんばんは)、Svelte不定期連載その5です。
過去の記事はこちら

  1. SvelteKit + Svelte を1年間くらい使ってみた知見など※SvelteKit メジャーリリース対応済み
  2. Svelteと他JSフレームワークとの比較 - Svelte不定期連載-01
  3. Svelteでユニットテスト - Svelte不定期連載-02
  4. SvelteでStorybookを使ってみる - Svelte不定期連載-03
  5. 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もあるので日本語ドキュメントもありとても助かります :)

svelte.config.js
// これがなければ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が正解なのでした。

https://kit.svelte.jp/docs/load#universal-vs-server

これもドキュメントを読めば…!といったところですね。ドキュメントは最高。

サーバーサイドのみで実行したい場合の正解例

src/routes/+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ではこんな形で簡単に行なえました。

src/components/Meta.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}
src/routes/+page.svelte
<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コンポーネントを作って読み込むことができます。

またわざわざ作らなくても、こんな素敵なプラグインもあります。
https://github.com/oekazuma/svelte-meta-tags

感謝…!!!!!

それぞれのライフサイクルのつかいどころ

最後に避けては通れぬライフサイクル関数について

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するチュートリアルも書いてあるのでぜひお試しください)

https://twitter.com/gihyosd/status/1669533941483864072?s=20

Facebook

関連記事 | Related Posts

We are hiring!

【フロントエンドエンジニア(コンテンツ開発)】新車サブスク開発G/東京

新車サブスク開発グループについてTOYOTAのクルマのサブスクリプションサービスである『 KINTO ONE 』のWebサイトの開発、運用をしています。​業務内容トヨタグループの金融、モビリティサービスの内製開発組織である同社にて、自社サービスである、クルマのサブスクリプションサービス『KINTO ONE』のWebサイトコンテンツの開発・運用業務を担っていただきます。

【フロントエンドエンジニア】新車サブスク開発G/東京

新車サブスク開発グループについてTOYOTAのクルマのサブスクリプションサービスである『 KINTO ONE 』のWebサイトの開発、運用をしています。​業務内容トヨタグループの金融、モビリティサービスの内製開発組織である同社にて、自社サービスである、TOYOTAのクルマのサブスクリプションサービス『KINTO ONE』のWebサイトの開発、運用を行っていただきます。