Upgrade to Pro
— share decks privately, control downloads, hide ads and more …
Speaker Deck
Features
Speaker Deck
PRO
Sign in
Sign up for free
Search
Search
Nuxtにおける設計
Search
Sigma
October 10, 2022
Programming
100
0
Share
Embed
Copy iframe code
Copy JS code
Copy link
Start on current slide
Nuxtにおける設計
Sigma
October 10, 2022
More Decks by Sigma
See All by Sigma
Proxmox_VE.pdf
seiyasugimoto
0
230
Stable Diffusionで遊んでみた
seiyasugimoto
1
150
EVAフレームワーク
seiyasugimoto
0
120
SSR+SPA
seiyasugimoto
0
160
Atomic Designを ディレクトリ以外で表現
seiyasugimoto
0
93
throttleすげぇぇぇ
seiyasugimoto
0
87
スマホでPythonしたい
seiyasugimoto
0
75
平文で保存するな!
seiyasugimoto
0
99
ソースコードを読もう
seiyasugimoto
0
99
Other Decks in Programming
See All in Programming
LLMによるContent Moderationの本番運用の裏側と品質担保への挑戦
suikabar
3
860
Laravelで学ぶ Webアプリケーションチューニング入門/web_application_tuning_101
hanhan1978
4
940
どこまでゆるくて許されるのか
tk3fftk
0
500
フィードバックで育てるAI開発
kotaminato
1
120
琵琶湖の水は止められてもNet--HTTPのリトライは止められない / You might be able to stop the water flow of Lake Biwa but you can't stop Net::HTTP retries
luccafort
PRO
0
400
「正の参照」と 「負の導出」で組む ハーネスエンジニアリング
cottpan
1
140
トークンをケチるな、設計しろ:GitHub Copilotを賢く使うコンテキスト戦略
ochtum
0
320
吝嗇家のためのAI活用 / AI development for miser - ChatGPT + Issue Driven Development
tooppoo
0
190
気圧・高度・GPSを記録&可視化するアプリ「Koudo」を作った話
hjmkth
1
360
Laravel Boostに学ぶ、AIにPHPを書かせる技術 〜OSSの実装から蒸留するエージェント制御の王道〜
kentaroutakeda
3
470
Claude Opus 4.6以後の受託開発エンジニアの変化(Claude Code開発ノウハウ大公開スペシャルbyクラスメソッド)
iidatakuma
1
800
【やさしく解説 設計編 #1】「ドメイン駆動」と「実装駆動」ってなに? 〜設計の考え方を、たとえ話で学ぼう〜
panda728
PRO
1
120
Featured
See All Featured
Noah Learner - AI + Me: how we built a GSC Bulk Export data pipeline
techseoconnect
PRO
0
220
What does AI have to do with Human Rights?
axbom
PRO
1
2.3k
Max Prin - Stacking Signals: How International SEO Comes Together (And Falls Apart)
techseoconnect
PRO
0
200
How to Talk to Developers About Accessibility
jct
2
410
Ten Tips & Tricks for a 🌱 transition
stuffmc
0
150
Practical Tips for Bootstrapping Information Extraction Pipelines
honnibal
25
2k
Templates, Plugins, & Blocks: Oh My! Creating the theme that thinks of everything
marktimemedia
31
2.8k
Jess Joyce - The Pitfalls of Following Frameworks
techseoconnect
PRO
1
190
Cheating the UX When There Is Nothing More to Optimize - PixelPioneers
stephaniewalter
287
14k
Exploring anti-patterns in Rails
aemeredith
3
450
Design in an AI World
tapps
1
260
Visualizing Your Data: Incorporating Mongo into Loggly Infrastructure
mongodb
49
10k
Transcript
Nuxtにおける設計 Composition APIの影響
プロフィール • 25歳 • 男性 • シニア・エンジニア ◦ フロントエンド ◦
株式会社エヌエルプラス • 開発案件の初期から関わって設計から入ることが多い ◦ ファッション通販サイトのコミュニティサービス ◦ 医療関係の B to B to C サービス
現代のフロントエンドには設計が必要なんだ • フロントエンドは年々リッチになってきている。 ◦ ブラウザの性能が向上した。 ◦ アプリケーションのような UIのWebサービスを提供する企業が増加し、エンドユーザーもお客さんも そういったWebサービスを使っている。 •
フロントエンドでサービスを統合することも増えている。 ◦ Firebaseの各種サービスをフロントエンドから使う。 ◦ チャットシステムをフロントエンドから使う。 ◦ ヘッドレスCMSをフロントエンドから使う。 ◦ WebRTC関係のソリューションをフロントエンドから使う。
Nuxtにおける設計とCompositionAPIの影響 • Option API から Composition API • Nuxt とディレクトリ構造の考え方
• Composition API の設計への影響
ついに Nuxt3 が来た • Vue3 ベースの Nuxt3 がようやくパブリックベータになった! • ビルドツールとして
Vite が標準になった他、ようやく Nuxt で Composition API が 正式に使えるようになる🎉
Option API から Composition API に変わる • 言い換えれば ◦ Option
API: Vue のオブジェクトを拡張することで機能を実現する方法 ◦ Composition API: Vue オブジェクトに対する DI によって機能を実現する方法 • 現状よく使われている vue class decorator により近い Class API を提供する方法 も考えられたらしい ◦ stage2 proposal の Decorator を使う必要があり不確実らしい ◦ TSXサポートに課題が出てくるらしい ◦ rfcs/0013-composition-api.md at master · vuejs/rfcs · GitHub ◦ tc39/proposals: Tracking ECMAScript Proposals
template で使う変数や関数を setup() を通じて注入する
• テスタブル ◦ 純粋な TypeScript のコードを注入するので、注入するコードの単体テストが書きやすい • リユーザブル ◦ 純粋な
TypeScript のコードを注入するので、使い回しやすい • TypeScript サポート ◦ 外部ライブラリに頼らない TypeScript サポートを実現 Composition API の特徴
Nuxtを使ったフロントエンドのディレクトリ構造(抜粋) • layouts/ Nuxt の標準 layouts/default.vue は pages/ 以下のページコンポーネントにデフォルトで適用される。 •
components/ Nuxt の標準 • pages/ Nuxt の標準 pages/ 以下のディレクトリ構造に従って Vue Router のルーティングが生成される。 • services/ View を責務とするコンポーネント群を、 API スキーマやロジックの変更の影響から隔離するためのサービス層。 ◦ api/ それぞれの API 関係の関数、共通処理等 ◦ dataTransfer/ API スキーマからコンポーネントの要求するデータ型への変換 ◦ linkBuilder/ ID 等からリンクを生成するコード ◦ logic/ サービスロジック等 • errors/ フロントエンドのエラー処理 • validations/ バリデーションのルールとエラー • @types/ 型を置く • typeGuards/ 型ガードを置く
考え方 • layouts/ pages/ components/ 以下に直接書かれるロジックを最小限にする。これ らは View に関心を持っている。 •
components/ 以下のディレクトリ構造はコンポーネントの役割に基づいたものにす る。 ◦ atomic design 等に基づく粒度等の情報はドキュメント等に記載する。 • 上記以外のディレクトリは横断的関心事に基づいていることが多い。 ◦ コンポーネント内で起こるエラーのエラー処理 ◦ フォーム関係のコンポーネントのバリデーション ◦ API呼び出しとそれに関する共通処理
Composition API の設計への影響 • components/ 等 Vue のコンポーネントを記述するディレクトリでテストが書きやす い。 ◦
component/Hoge/Fuga.vue ◦ component/Hoge/FugaSetup.ts ◦ component/Hoge/FugaSetup.spec.ts ◦ というような形で単体テストが書ける • Vue のコンポーネントからロジックを剥がしやすい ◦ setupを書いている.tsファイルから切り出すだけ • 既存の方針を強化するように働いている
まとめ • Vue3 ベースの Nuxt3 がようやくリリース間近になったことで、 Nuxt にも Composition API
の波が来た • これまでの Nuxt では、 Vue のコンポーネントを書く場所とそれ以外を分けて考え、 横断的関心事を関数として切り出して特定のディレクトリにまとめる方法を取ってき た • Composition API はそういった方針を強化すると考えられる