Upgrade to Pro
— share decks privately, control downloads, hide ads and more …
Speaker Deck
Sign up for free
Menu
Search
Features
All features
Private URLs
Password Protection
Custom URLS
Scheduled publishing
Remove Branding
Restrict embedding
Deck Collections
Notes
Features
All features
Private URLs
Password Protection
Custom URLS
Scheduled publishing
Remove Branding
Restrict embedding
Deck Collections
Notes
Explore
Featured decks
Featured speakers
Programming
Technology
Storyboards
Explore
Featured decks
Featured speakers
Programming
Technology
Storyboards
Pricing
Search
Sign in
Sign up for free
componentの分け方
Search
Sponsored
·
Your Podcast. Everywhere. Effortlessly.
Share. Educate. Inspire. Entertain. You do you. We'll handle the rest.
→
yuto hara
October 15, 2018
100
0
Share
Embed
Copy iframe code
Copy JS code
Copy link
Start on current slide
componentの分け方
社内勉強会
yuto hara
October 15, 2018
More Decks by yuto hara
See All by yuto hara
テストカバレッジ100%のプロジェクトで学んだ、 ユニットテストの書き方
hxrxchang
1
2k
SPAの状態管理
hxrxchang
0
550
インドカレー屋で学ぶ非同期処理
hxrxchang
1
660
Featured
See All Featured
Dealing with People You Can't Stand - Big Design 2015
cassininazir
367
27k
Writing Fast Ruby
sferik
630
63k
GraphQLとの向き合い方2022年版
quramy
50
15k
Measuring & Analyzing Core Web Vitals
bluesmoon
9
1.1k
Context Engineering - Making Every Token Count
addyosmani
9
1.3k
Tell your own story through comics
letsgokoyo
1
1.1k
The Curious Case for Waylosing
cassininazir
1
610
Evolution of real-time – Irina Nazarova, EuRuKo, 2024
irinanazarova
9
1.7k
Optimising Largest Contentful Paint
csswizardry
37
4k
Organizational Design Perspectives: An Ontology of Organizational Design Elements
kimpetersen
PRO
1
880
Leo the Paperboy
mayatellez
10
2.4k
How to make the Groovebox
asonas
2
2.5k
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