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
componentの分け方
Search
yuto hara
October 15, 2018
0
84
componentの分け方
社内勉強会
yuto hara
October 15, 2018
Tweet
Share
More Decks by yuto hara
See All by yuto hara
テストカバレッジ100%のプロジェクトで学んだ、 ユニットテストの書き方
hxrxchang
1
2k
SPAの状態管理
hxrxchang
0
500
インドカレー屋で学ぶ非同期処理
hxrxchang
1
630
Featured
See All Featured
For a Future-Friendly Web
brad_frost
180
9.9k
How To Stay Up To Date on Web Technology
chriscoyier
791
250k
Optimising Largest Contentful Paint
csswizardry
37
3.4k
KATA
mclloyd
32
15k
Product Roadmaps are Hard
iamctodd
PRO
54
11k
Intergalactic Javascript Robots from Outer Space
tanoku
273
27k
Why Our Code Smells
bkeepers
PRO
339
57k
The Psychology of Web Performance [Beyond Tellerrand 2023]
tammyeverts
49
3.1k
Raft: Consensus for Rubyists
vanstee
139
7.1k
Reflections from 52 weeks, 52 projects
jeffersonlam
352
21k
"I'm Feeling Lucky" - Building Great Search Experiences for Today's Users (#IAC19)
danielanewman
229
22k
Navigating Team Friction
lara
189
15k
Transcript
componentの分け方 monotips #14
前回の続きです。詳しくは↓ https://speakerdeck.com/hxrxchang/spafalsezhuang-tai-guan-li-d860a75 0-150e-46d0-a14f-eb1730b9c875
前提知識: component指向、状態管理 SPAでは、入れ子構造になっているcomponentの組み合 わせでアプリケーションを構成する。 状態はReduxとかvuexとかngrxみたいなライブラリを使っ て管理する。
store component client side Backend HTTP dispatch action Select
Componentの分け方 Container Component Presentational Component
Container Component Storeから状態をSelectする。 子供の関係にあるPresentational Componentに値を 渡す。 Actionをdispatchする。
Presentational Component 親の関係にあるContainer Componentから 値を受け取り、それを描画するだけ。 ロジックは極力持たない。
両方を囲っているのが detailComponent => Container Component 画像の部分は imageViewComponent => Presentational Component
詳細の部分は detailInfoComponent => Presentational Component
componentを分ける理由 reducer / component の責務をさらに分離。 storeとやりとりするcomponent(container component)と、 viewを表示するcomponent(presentational component)の 責務を分けて、どこでなにをやってるかさらに分かり易くする。
テストを書き易くする
以上が前回の振り返りです。
課題: componentの分け方、粒度 - 肥大化するcontainer component と presentational component - container
component , presentational component だけだと足りない!!
肥大化のデメリット - 果てしない行数は可読性を下げる。 - component指向なのに再利用ができない。 - 1つのcomponentに複数機能があるとテストがしづらい。
componentの分け方 - componentの粒度、役割を決めないとこれもまた難読化に - 分けるにしても人によって粒度がバラバラ - 個人プロジェクトでも時期によってあーでもないこーでもない - componentの分け方のルール =
“設計” が大事
Atomic Design ページを - Atoms (原子) - Molecules (分子) -
Organism (有機体) - template (エンジニアは意識しなくても良さそう) - pages に分ける。
Atoms これ以上分解不可能な最小単位 例: (単体の)テキストボックスやボタンなど Molecules Atomsを組み合わせて最小単位の機能を作る 例: テキストボックスとボタンを組み合わせて 検索フォームを作る
Organisms 1つの独立した機能となるもの。 MoleculesとAtomsを組み合わせる。 Storeとやりとりする。 Pages Organismsを組み合わせて、ページを作る
None
componentの単位 - basics - components - containers - pages storeとやりとりするのはcontainersとpages
Atomic Designでもオリジナルの設計でも共通するもの - storeとやりとりするcomponentと、 表示専用のcomponentの分離 = container component と presentational
componentの拡張
Nuxtが良さそう - pages dirでルーティング - components dirの中でatoms, molecules, organisms =>
これだけで設計完了 - 導入事例がたくさん - reduxよりvuexの方がわかりやすそう。 - typescript, rxjs要らない
None