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
Composerが「依存解決」のためにどんな工夫をしているか #phpcon
o0h
PRO
1
210
エンジニア向け採用ピッチ資料
inusan
0
160
設計やレビューに悩んでいるPHPerに贈る、クリーンなオブジェクト設計の指針たち
panda_program
6
1.2k
地方に住むエンジニアの残酷な現実とキャリア論
ichimichi
5
1.3k
Go1.25からのGOMAXPROCS
kuro_kurorrr
1
800
第9回 情シス転職ミートアップ 株式会社IVRy(アイブリー)の紹介
ivry_presentationmaterials
1
230
AWS CDKの推しポイント 〜CloudFormationと比較してみた〜
akihisaikeda
3
310
What Spring Developers Should Know About Jakarta EE
ivargrimstad
0
210
Beyond Portability: Live Migration for Evolving WebAssembly Workloads
chikuwait
0
390
ドメインモデリングにおける抽象の役割、tagless-finalによるDSL構築、そして型安全な最適化
knih
11
2k
Cursor AI Agentと伴走する アプリケーションの高速リプレイス
daisuketakeda
1
130
アンドパッドの Go 勉強会「 gopher 会」とその内容の紹介
andpad
0
260
Featured
See All Featured
RailsConf 2023
tenderlove
30
1.1k
A designer walks into a library…
pauljervisheath
206
24k
Keith and Marios Guide to Fast Websites
keithpitt
411
22k
Product Roadmaps are Hard
iamctodd
PRO
53
11k
Documentation Writing (for coders)
carmenintech
71
4.9k
BBQ
matthewcrist
89
9.7k
Making the Leap to Tech Lead
cromwellryan
134
9.3k
CSS Pre-Processors: Stylus, Less & Sass
bermonpainter
357
30k
Templates, Plugins, & Blocks: Oh My! Creating the theme that thinks of everything
marktimemedia
31
2.4k
Music & Morning Musume
bryan
46
6.6k
Six Lessons from altMBA
skipperchong
28
3.8k
The Pragmatic Product Professional
lauravandoore
35
6.7k
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をご参照ください!
ご静聴ありがとうございました!