「+page.server.tsって結局なにを置けばいいんだ……？」

Svelte Japan Offline Meetup #5

Transcript

1. 「+page.server.tsって結局な にを置けばいいんだ……？」 ひとしろ
2. 自己紹介 ひとしろ • QAエンジニア • 愛知のはじっこ在住 • 人生で初めての技術イベント登壇
3. SvelteKitをぽちぽちしてて思った
4. Routing（ルーティング） • +page.svelte : アプリのページ定義だね • +page.ts : クライアント側でAPIとかあらかじめ叩くときに使うんだろうね • +error.svelte : エラーページ定義 • +layout（以下略） : 特定のパス以下に共通の定義したいときに使うんだね • +server.ts : エンドポイントが作れるんだね
5. 「+page.server.tsって結局なに を置けばいいんだ……？」
6. ネタバレ：　コントローラー
7. +page.server.ts load 関数をサーバー上でのみ実行できるようにしたい場合 — 例えば、データベー スからデータを取得したり、API キーのようなプライベートな環境変数にアクセスし たりする必要がある場合 — +page.js を +page.server.js にリネームし、 PageLoad 型を PageServerLoad に変更します。 「モノリスだし大抵のことは +page.server.tsに書くことになりそう～」
8. この+page.server.tsデカくね？
9. 巨大+page.server.ts問題 export const actions: Actions = { login: async({ request }) => { // たくさんの処理... } logout: async({ request }) => { // たくさんの処理... } follow: async({ request }) => { // たくさんの処理... } }
10. 巨大+page.server.ts問題 export const actions: Actions = { login: async({ request }) => { // たくさんの処理... } logout: async({ request }) => { // たくさんの処理... } follow: async({ request }) => { // たくさんの処理... } } ファイルを分けたい （安直な発想）
11. 名前つきActionってページと異なるパスに置けないかな？ 答え：　無理 +page.server.tsのActionsは、 Actionsが定義されているパスの +page.svelteを返そうとする
12. 名前つきActionってページと異なるパスに置けないかな？ <form method="POST" action="/api/login?/login" > <label> Email <input name="email" type="email"> </label> <label> Password <input name="password" type="password"> </label> <button>Log in</button> </form> 📁api └ 📄+page.server.ts 📁login └ 📄+page.svelte /loginからSubmitして処理したあと、 /api/login/+page.svelteを探す → 404 Not Found
13. 名前つきActionってページと異なるパスに置けないかな？ 📁api └ 📄+page.server.ts export const actions: Actions = { login : async () => { 　　　　　　// 処理してから 　　　　　　// リダイレクトしちゃおう redirect(303, '/login'); } } こうすれば/loginに戻ってはこれるが、 SvelteKitの良いやり方ではない
14. Remote functionsで解決しないかな？ 答え：　部分的に解決するが、完全には解決しない 巨大+page.server.tsが巨大hogehoge.remote.tsになるだけ……たぶん • hogehoge.remote.ts, fugafuga.remote.ts…とファイルは分けられる • 次は「hogehoge.remote.tsって結局なにを置けばいいんだ ……？」に問題がス ライド
15. Remote functionsで解決しないかな？ 公式ドキュメントでは DBクエリまで直書きしてるけど、 そのまま真似するのは危険すぎる （さすがにわかる）
16. 落ち着いてアーキテクチャから考えよう 「響きがカッコイイから」って理由だけで 関数型言語でもないのに読んだコレ→ 任意のアーキテクチャに置き換えて楽しんでください
17. +page.server.ts（と、*.remote.ts)って何層なんだ？ 引用: 関数型ドメインモデリング p.52
18. +page.server.ts（と、*.remote.ts)って何層なんだ？ 引用: 関数型ドメインモデリング p.52
19. +page.server.ts（と、*.remote.ts)って何層なんだ？ 引用: 関数型ドメインモデリング p.52
20. ワークフローの境界に責務がありそう リ ク エ ス ト D T O コ マ ン ド ス テ ッ プ イ ベ ン ト D T O レ ス ポ ン ス
21. ワークフローの境界に責務がありそう リ ク エ ス ト D T O コ マ ン ド ス テ ッ プ イ ベ ン ト D T O レ ス ポ ン ス
22. つまり何をする 1. 渡された各種パラメータからドメインを生成して 2. ワークフローを呼んで 3. ワークフローの戻り値をシリアライズして 4. 返す →　いわゆるコントローラー
23. スッキリ
24. なぜここまで迷走したのか • アーキテクチャのことよく知らなかった • REST APIの例が多く、うまく結びついてなかった • コードの単なる見た目やファイル名ではなく、 「ここは何の役割を担っているのか？」という本質を見よう
25. 余談: Remote functions検証を通過した オブジェクトはドメインになりうる？
26. 個人的な答え： ならない • 検証は検証であってドメインを生成し たことにはならない • スキーマをRemote functionsの引数 に渡せば、 ドメイン生成するときの検証はできる が…… ◦ form関数なら独自の検証関数を そのまま入れられる
27. Remote Functionsの検証に何を期待しようか？ • Remote Functionsの検証にガッツリ期待して、スキーマに必要な検証をぜんぶ書 いておく ◦ Remote Functionsの検証を全面的に信頼 ◦ 小規模なアプリケーションなら正直これで全然よさそう • ドメインとしてはあくまで未検証として扱う ◦ 「これは何者なのか？」の見通しは良くなる ◦ ちゃんとDDDするならこれかな？
28. 最後に • 「+page.server.tsって結局なにを置けばいいんだ……？」 ◦ コントローラーに置くべきものを置こう！ ▪ コントローラー以外のものを置いちゃうとFatになるよ！ ◦ Remote functionsの動向にも注目しよう！
29. もっと最後に 「TypeScriptで関数型ドメインモデリングつまみ食いメモ」 Zennでスクラップしています。 まだ勉強したてですが、よければ覗いていってください お気軽コメント歓迎です！
30. ありがとうございました