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.5k
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
4.9k
Other Decks in Programming
See All in Programming
カスタムしながら理解するGraphQL Connection
yanagii
1
1.5k
Quine, Polyglot, 良いコード
qnighy
4
610
JavaでLチカしたい! / JJUG CCC 2024 Fall LT
nhayato
0
110
Duckdb-Wasmでローカルダッシュボードを作ってみた
nkforwork
0
100
Amazon Qを使ってIaCを触ろう!
maruto
0
370
約9000個の自動テストの 時間を50分->10分に短縮 Flakyテストを1%以下に抑えた話
hatsu38
24
12k
CSC509 Lecture 09
javiergs
PRO
0
140
リアーキテクチャxDDD 1年間の取り組みと進化
hsawaji
1
180
破壊せよ!データ破壊駆動で考えるドメインモデリング / data-destroy-driven
minodriven
17
4.3k
3rd party scriptでもReactを使いたい! Preact + Reactのハイブリッド開発
righttouch
PRO
1
580
PLoP 2024: The evolution of the microservice architecture pattern language
cer
PRO
0
2.3k
LLM生成文章の精度評価自動化とプロンプトチューニングの効率化について
layerx
PRO
2
170
Featured
See All Featured
A Tale of Four Properties
chriscoyier
156
23k
Visualizing Your Data: Incorporating Mongo into Loggly Infrastructure
mongodb
42
9.2k
Adopting Sorbet at Scale
ufuk
73
9.1k
What’s in a name? Adding method to the madness
productmarketing
PRO
22
3.1k
[RailsConf 2023] Rails as a piece of cake
palkan
51
4.9k
The Cult of Friendly URLs
andyhume
78
6k
Designing the Hi-DPI Web
ddemaree
280
34k
Designing Dashboards & Data Visualisations in Web Apps
destraynor
229
52k
Navigating Team Friction
lara
183
14k
How to train your dragon (web standard)
notwaldorf
88
5.7k
Building Better People: How to give real-time feedback that sticks.
wjessup
364
19k
Faster Mobile Websites
deanohume
305
30k
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をご参照ください!
ご静聴ありがとうございました!