Lock in $30 Savings on PRO—Offer Ends Soon! ⏳
Speaker Deck
Features
Speaker Deck
PRO
Sign in
Sign up for free
Search
Search
Nuxt.jsプロジェクトの改善テクニック
Search
yamish
June 21, 2020
Programming
3
2.7k
Nuxt.jsプロジェクトの改善テクニック
@チャリティーカンファレンス沖縄 vol.1 フロントエンド編
2020 / 6 / 21 (Sun)
https://charity-conf.okinawa.jp/
yamish
June 21, 2020
Tweet
Share
More Decks by yamish
See All by yamish
ブックマークレットを使おう!
yamish123
0
5.6k
Other Decks in Programming
See All in Programming
愛される翻訳の秘訣
kishikawakatsumi
3
340
Developing static sites with Ruby
okuramasafumi
0
320
クラウドに依存しないS3を使った開発術
simesaba80
0
140
Context is King? 〜Verifiability時代とコンテキスト設計 / Beyond "Context is King"
rkaga
10
1.4k
Findy AI+の開発、運用におけるMCP活用事例
starfish719
0
1.6k
Microservices rules: What good looks like
cer
PRO
0
1.6k
Github Copilotのチャット履歴ビューワーを作りました~WPF、dotnet10もあるよ~ #clrh111
katsuyuzu
0
120
認証・認可の基本を学ぼう後編
kouyuume
0
250
FluorTracer / RayTracingCamp11
kugimasa
0
250
perlをWebAssembly上で動かすと何が嬉しいの??? / Where does Perl-on-Wasm actually make sense?
mackee
0
110
UIデザインに役立つ 2025年の最新CSS / The Latest CSS for UI Design 2025
clockmaker
18
7.7k
令和最新版Android Studioで化石デバイス向けアプリを作る
arkw
0
430
Featured
See All Featured
Cheating the UX When There Is Nothing More to Optimize - PixelPioneers
stephaniewalter
286
14k
Thoughts on Productivity
jonyablonski
73
5k
GitHub's CSS Performance
jonrohan
1032
470k
The Web Performance Landscape in 2024 [PerfNow 2024]
tammyeverts
12
980
Impact Scores and Hybrid Strategies: The future of link building
tamaranovitovic
0
170
ReactJS: Keep Simple. Everything can be a component!
pedronauck
666
130k
Dealing with People You Can't Stand - Big Design 2015
cassininazir
367
27k
Designing Experiences People Love
moore
143
24k
Fantastic passwords and where to find them - at NoRuKo
philnash
52
3.5k
Navigating Weather and Climate Data
rabernat
0
47
Information Architects: The Missing Link in Design Systems
soysaucechin
0
710
What's in a price? How to price your products and services
michaelherold
246
13k
Transcript
Nuxt.js プロジェクトの 改善テクニック CBcloud株式会社 宮脇 駿 @CHARITY CONFERENCE OKINAWA vol.1 FRONTEND 2020
/ 06 / 21
自己紹介 • 宮脇 駿 (みやわき しゅん) • 28歳、エンジニア歴4年、Vue.js歴3年 • 経歴 ◦ 2016 -
2020 NTTデータイントラマート ◦ 2020 - CBcloud • フロントエンド(Vue.js, Nuxt.js)を中心とした開発を担当 ◦ 最近Railsも触れるようになりました
None
None
None
本日お話すること
None
https://ja.nuxtjs.org/
None
実際にNuxt.js(Vue.js) でプロダクト開発を行う上で、 陥りがちな罠や、それに対する改善案を紹介していきます!
Vuex、コンポーネント設計
Vue___Vuex_のアーキテクチャ完全に理解した .pdf https://speakerdeck.com/entaku/vue-vuex-falseakitekutiyawan-quan-nili-jie-sita 弊社PMの発表資料(2019年)
Vuex × Atomic Designアーキテクチャを採用
Vuex × Atomic Designアーキテクチャを採用
Vuex × Atomic Designアーキテクチャを採用 • API ◦ サーバとのrequest, responseのやり取 りを直接行う
• Repository ◦ StoreとAPIとのつなぎを行う ◦ Responseに型を付けてdomain class としてstoreに返す • Store ◦ Vuex store ◦ Pages, Organismsからアクセス可 • Pages, Organisms, Molecules, Atoms ◦ Atomic Design
Vuex × Atomic Designアーキテクチャを採用 • Domain class ◦ API responseをクラス化して型を付け
たもの ◦ responseをprivateフィールドに格納し、 getter, setterでアクセスする ◦ サーバから取得するデータは基本的に この形式に変換して扱う ◦ フィールドを組み合わせたパラメータ や、isXXX系のフラグもここで定義でき るので便利
Vuex × Atomic Designアーキテクチャを採用 • API ◦ サーバとのrequest, responseのやり取 りを直接行う
• Repository ◦ StoreとAPIとのつなぎを行う ◦ Responseに型を付けてdomain class としてstoreに返す • Store ◦ Vuex store ◦ Pages, Organismsからアクセス可 • Pages ◦ Nuxt page • Organisms, Molecules, Atoms ◦ Atomic Design
実際にやっていく間にこうなった
大小様々なOrganismsが好き勝手に Storeにアクセスしてカオス化 Oganismsが好き勝手にStoreにアクセス することで、処理の流れが追えない Storeを利用している箇所が多すぎて 影 響範囲が全く掴めなくなっていた データの不整合が発生 1500行近くあるStoreも。。。 結果、機能追加が怖くて出来なくなる
大小様々なOrganismsが好き勝手に Storeにアクセスしてカオス化 1500行あるVuex Store Oganismsが好き勝手にStoreにアクセス することで、処理の流れが追えない Storeを利用している箇所が多すぎて 影 響範囲が全く掴めなくなっていた データの不整合が発生 1500行近くあるStoreも。。。
結果、機能追加が怖くて出来なくなる
なぜ巨大なStoreが生まれたのか
なぜカオスになったのか • 1500行のVuex Store ◦ 共通的なロジックや、便利そうな isXXX系フラグなどをとりあえず Storeに放り込んでしまっていた ◦ prop,
emit渡しをスキップするため に利用していそうなケースも • Organismsが多い ◦ Atomic Designの区切りに迷って Organismsにしていそうなケースが 多かった
こんな感じの作りに統一した
PageからのみStoreにアクセスする
PageからのみStoreにアクセスする データの流れが一本化するので、処理が 追いやすくなった 気軽にStoreを使えないので、ロジックの 分離を無意識に行える(気がする) ただ、これだとすべての非同期通信を Pages経由でやり取りするので不便では ないか?
例えばこういう部品とか
Pageを経由しないで非同期通信をしたい部品 住所が入力されたらGeocode APIを叩き、 緯度・経度を親に返すような部品 住所を入力してください ... Google Maps API 東京都千代田区神田練塀町
東京都千代田区神田練塀町 request 緯度・経度 response
これを
こうした
async component と Storeの分割 • 自己完結的に非同期通信を行う asyncコンポーネント の概念を入れた • asyncコンポーネントはResource
Storeを経由してAPI を利用する ◦ Resouce Storeはstateを持たないため、 状 態の不整合が起きることを防ぐ ◦ async コンポーネントはResouce Store経由で取 得したデータをコンポーネント内に保持し、自己 完結的に利用する • カオスになった思い出があるので、 Storeにstateを置 いてどこからでも参照できるようにはしたくなかった
• プロジェクトやメンバーの性質に合わせてルールを決める ◦ メンバーも実装を進める上で上手くなっていく。現行のプロジェクトで理想の設計を追求するので はなく、次回のプロジェクトでもっと良い設計が出来ればいい。 ◦ 調べて出てくる一般論を適用してそのまま上手くいくわけではない。 ◦ 常に考えながら改善していくのが大事! •
「何でも出来る」設計だと、混沌としやすい(気がする) ◦ 制限をしつつ、ルールを決めた上で「出来ることを増やす」方がラク? Store・コンポーネント設計する上で
TypeScriptの導入
今だと結構簡単に使えます
https://typescript.nuxtjs.org/ja/
コンポーネントもVuex StoreもClassでかけます https://typescript.nuxtjs.org/ja/cookbook/components/#script
コンポーネントもVuex StoreもClassでかけます https://typescript.nuxtjs.org/ja/cookbook/store.html
非TypeScriptプロジェクトへ導入する上で • 一気に全部やろうとしない ◦ コンポーネントごと、 Storeごとで部分導入可能 ◦ できるところから無理せず導入する(一気にやろうとすると断念しがち) • Props,
emitでは型情報が失われるので注意 ◦ 後付で型を定義出来るが、完全に疎通できるわけではない。イベント名の typoも防げない。 • テンプレート内ロジックを使わないようにする ◦ 現段階ではテンプレート内ロジックには TypeScriptは効かないため、computedに逃がすなどする 必要がある
例えばこの場合 • todoはnullの可能性があるが、 TypeScriptには検出出来ない • TodoItem型の仕様が変わった場 合などにも影響に気づきにくい
こうすると良い • script内に定義することで、 TypeScriptを活かした形で書ける • null参照や変数名のTypoもしっかり チェックしてくれる • Optional chainingも使える!
非TypeScriptプロジェクトへ導入する上で • 一気に全部やろうとしない ◦ コンポーネントごと、 Storeごとで部分導入可能 ◦ できるところから無理せず導入する(一気にやろうとすると断念しがち) • Props,
emitでは型情報が失われるので注意 ◦ 後付で型を定義出来るが、完全に疎通できるわけではない。イベント名の typoも防げない。 • テンプレート内ロジックを使わないようにする ◦ 現段階ではテンプレート内ロジックには TypeScriptは効かないため、computedに逃がすなどする 必要がある
最後に
最後に • 既存実装のいい点・悪い点を普段から意識しておく ◦ その上で、大きくリファクタリング出来るようになったタイミングで実践する ◦ 一気にまるごと変えるのではなく、小さく修正していける仕組みを考える • メンバーで話し合いながら、チーム・プロジェクトに合わせて設計・意思決定 をしていくのが重要のはず
• うちではこんな感じで困っている、こうしたら上手く行ったなどあれば是非 お 話を伺いたいです!
一緒に働く仲間を募集しています! https://www.wantedly.com/companies/cb-cloud https://www.green-japan.com/company/4712 Wantedly, Greenをご参照ください!
ご静聴ありがとうございました!