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.jsプロジェクトの改善テクニック
Search
yamish
June 21, 2020
Programming
3
2.6k
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.4k
Other Decks in Programming
See All in Programming
[初登壇@jAZUG]アプリ開発者が気になるGoogleCloud/Azure+wasm/wasi
asaringo
0
130
A comprehensive view of refactoring
marabesi
0
970
Webの外へ飛び出せ NativePHPが切り拓くPHPの未来
takuyakatsusa
1
200
ktr0731/go-mcpでMCPサーバー作ってみた
takak2166
0
170
Kotlin エンジニアへ送る:Swift 案件に参加させられる日に備えて~似てるけど色々違う Swift の仕様 / from Kotlin to Swift
lovee
1
250
Team topologies and the microservice architecture: a synergistic relationship
cer
PRO
0
950
コードの90%をAIが書く世界で何が待っているのか / What awaits us in a world where 90% of the code is written by AI
rkaga
41
28k
既存デザインを変更せずにタップ領域を広げる方法
tahia910
1
240
AIコーディング道場勉強会#2 君(エンジニア)たちはどう生きるか
misakiotb
1
240
関数型まつり2025登壇資料「関数プログラミングと再帰」
taisontsukada
2
840
AWS CDKの推しポイント 〜CloudFormationと比較してみた〜
akihisaikeda
3
290
Benchmark
sysong
0
230
Featured
See All Featured
GraphQLの誤解/rethinking-graphql
sonatard
71
11k
Writing Fast Ruby
sferik
628
61k
Docker and Python
trallard
44
3.4k
Practical Tips for Bootstrapping Information Extraction Pipelines
honnibal
PRO
20
1.3k
It's Worth the Effort
3n
184
28k
Bootstrapping a Software Product
garrettdimon
PRO
307
110k
Intergalactic Javascript Robots from Outer Space
tanoku
271
27k
Statistics for Hackers
jakevdp
799
220k
A designer walks into a library…
pauljervisheath
206
24k
JavaScript: Past, Present, and Future - NDC Porto 2020
reverentgeek
48
5.4k
Music & Morning Musume
bryan
46
6.6k
Templates, Plugins, & Blocks: Oh My! Creating the theme that thinks of everything
marktimemedia
31
2.4k
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をご参照ください!
ご静聴ありがとうございました!