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
5.1k
Other Decks in Programming
See All in Programming
Оптимизируем производительность блока Казначейство
lamodatech
0
950
快速入門可觀測性
blueswen
0
500
ATDDで素早く安定した デリバリを実現しよう!
tonnsama
1
1.9k
月刊 競技プログラミングをお仕事に役立てるには
terryu16
1
1.2k
PHPとAPI Platformで作る本格的なWeb APIアプリケーション(入門編) / phpcon 2024 Intro to API Platform
ttskch
0
390
Amazon Nova Reelの可能性
hideg
0
200
アクターシステムに頼らずEvent Sourcingする方法について
j5ik2o
6
700
BEエンジニアがFEの業務をできるようになるまでにやったこと
yoshida_ryushin
0
200
Beyond ORM
77web
11
1.6k
はてなにおけるfujiwara-wareの活用やecspressoのCI/CD構成 / Fujiwara Tech Conference 2025
cohalz
3
2.7k
Lookerは可視化だけじゃない。UIコンポーネントもあるんだ!
ymd65536
1
130
functionalなアプローチで動的要素を排除する
ryopeko
1
200
Featured
See All Featured
Navigating Team Friction
lara
183
15k
How STYLIGHT went responsive
nonsquared
96
5.3k
The Illustrated Children's Guide to Kubernetes
chrisshort
48
49k
BBQ
matthewcrist
85
9.4k
Fontdeck: Realign not Redesign
paulrobertlloyd
82
5.3k
Into the Great Unknown - MozCon
thekraken
34
1.6k
CSS Pre-Processors: Stylus, Less & Sass
bermonpainter
356
29k
Exploring the Power of Turbo Streams & Action Cable | RailsConf2023
kevinliebholz
28
4.5k
Imperfection Machines: The Place of Print at Facebook
scottboms
267
13k
Building Better People: How to give real-time feedback that sticks.
wjessup
366
19k
Creating an realtime collaboration tool: Agile Flush - .NET Oxford
marcduiker
26
1.9k
Optimizing for Happiness
mojombo
376
70k
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をご参照ください!
ご静聴ありがとうございました!