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 / Vue 開発でやりがちな 「読みづらい」「わかりづらい」コード
Search
ショウノシオリ
July 24, 2019
Programming
0
190
Nuxt / Vue 開発でやりがちな 「読みづらい」「わかりづらい」コード
2019年7月24日 vkansai
ショウノシオリ
July 24, 2019
Tweet
Share
More Decks by ショウノシオリ
See All by ショウノシオリ
開発チームのリーダーとしてどうあるべきか?
sshono1210
3
1.2k
Nuxt.js のディレクトリ
sshono1210
0
2.9k
Nuxt.js で SSR 対応する
sshono1210
1
2.2k
array_merge と array_push の違いについて
sshono1210
0
470
全くデザインを勉強したことのないエンジニアが「なるほどデザイン」を読んで少しだけ勉強した話
sshono1210
0
190
Vue.js の methods と computed
sshono1210
0
91
すぐに使える ES2015 の基本構文3つ
sshono1210
0
63
肌で感じたディレクションとマネジメント
sshono1210
0
55
Vue.jsで遊んでみよう
sshono1210
0
69
Other Decks in Programming
See All in Programming
ローコードサービスの進化のためのモノレポ移行
taro28
1
310
CQRS+ES勉強会#1
rechellatek
0
370
新卒から4年間、20年もののWebサービスと 向き合って学んだソフトウェア考古学
oguri
7
6.3k
CRE Meetup!ユーザー信頼性を支えるエンジニアリング実践例の発表資料です
tmnb
0
110
小さく段階的リリースすることで深夜メンテを回避する
mkmk884
2
110
英語文法から学ぶ、クリーンな設計の秘訣
newnomad
1
260
JavaOne 2025: Advancing Java Profiling
jbachorik
1
300
安全に倒し切るリリースをするために:15年来レガシーシステムのフルリプレイス挑戦記
sakuraikotone
5
2k
RCPと宣言型ポリシーについてのお話し
kokitamura
2
130
なぜselectはselectではないのか
taiyow
2
270
requirements with math
moony
0
500
バックエンドNode.js × フロントエンドDeno で開発して得られた知見
ayame113
4
1.2k
Featured
See All Featured
Understanding Cognitive Biases in Performance Measurement
bluesmoon
27
1.6k
Bootstrapping a Software Product
garrettdimon
PRO
307
110k
Distributed Sagas: A Protocol for Coordinating Microservices
caitiem20
331
21k
Site-Speed That Sticks
csswizardry
4
440
Responsive Adventures: Dirty Tricks From The Dark Corners of Front-End
smashingmag
251
21k
CSS Pre-Processors: Stylus, Less & Sass
bermonpainter
356
30k
Building an army of robots
kneath
304
45k
Building Your Own Lightsaber
phodgson
104
6.3k
Fashionably flexible responsive web design (full day workshop)
malarkey
406
66k
Automating Front-end Workflow
addyosmani
1369
200k
Agile that works and the tools we love
rasmusluckow
328
21k
Git: the NoSQL Database
bkeepers
PRO
429
65k
Transcript
Nuxt / Vue 開発でやりがちな 「読みづらい」「わかりづらい」コード 株式会社chatbox エンジニア ショウノシオリ
v-if がめちゃくちゃ多い
props 渡しまくる
動くけど 「読みづらい」「分かりづらい」 コードになってしまっていることがある
「読みやすくする」「分かりやすくする」 にはどうすればいいか?
事例① v-if が多すぎる 問題点 ▷ DOM の見通しが悪くなる ▷ 書くのも面倒 ▷
ディレクティブに渡す値の変更に弱い
事例① の改善案 ロジック層を分離する ▷ 可読性アップ ▷ 「見た目」と「ロジック」に分けて考 えられる
事例② props を渡しすぎる 問題点 ▷ 子 → 親 に返す時が面倒になったりする (form
データとか) ▷ 子 の方にも props を書かないといけなのが面倒 ▷ 共通コンポーネントの props を増やしてしまうと、そ のコンポーネントを使っているページでの対応が必 要になったりする
事例② の改善案 意味のあるデータはまとめて渡す ▷ 子側で必要なプロパティが増えた時のことも考慮 ▷ プロパティは詳細に定義するほうがよい (渡し忘れたときにエラーとなって気付けるので) ▷ 場合によってはコンポーネント側でAPI発行もあり
事例③ 親子間での受け渡しフローがバラバラ イベントの発火、データを持つコンポーネントが親コンポーネントだったり、 子コンポーネントだったりする 問題点 ▷ 親でも子でも大抵動くようにコードを書くことはできるが、毎回探すのが 大変 ▷ 共通コンポーネントにしたときに困ることも
▷ 基本「子コンポーネントは親コンポーネントに使われる部品で、 描画に集中させる」と考える ▷ vuex も適切に利用すると良い ◦ ただし、vuex の管理コストとの兼ね合いを考慮 事例③
の改善案 基本は親にもたせる、実行させる
事例は色々あるけど そもそも...
Nuxt.js / Vue で 「読みづらい」「わかりづらい」 コードになってしまう原因は?
「役割」をよく考えずに なんとなく書いてしまっている からでは
Nuxt / Vue は自由度が高い 「なんとなく」でも それっぽく書けてしまう...
▷ 親コンポーネント と 子コンポーネント ▷ template / script / style
▷ ディレクトリ構成 ▷ ファイル名 ... それぞれに役割がある
構造的に責務が分割されていても コードを書く人が守れてないと勿体無い
「読みづらさ」「わかりづらさ」 を生み出すかどうかは開発者次第
その自由度に振り回されないよう 「どこに何をかくか」 「どうやって実装するか」 を考えることが大事
学習コストが低く、 手軽に導入しやすい Nuxt / Vue
コードの設計をよく考えて 最大限に活かそう
Thanks! Any questions? You can find me at: @username
[email protected]