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
Sponsored
·
Your Podcast. Everywhere. Effortlessly.
Share. Educate. Inspire. Entertain. You do you. We'll handle the rest.
→
yuto hara
October 15, 2018
95
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
540
インドカレー屋で学ぶ非同期処理
hxrxchang
1
660
Featured
See All Featured
Utilizing Notion as your number one productivity tool
mfonobong
4
330
GraphQLの誤解/rethinking-graphql
sonatard
75
12k
Reflections from 52 weeks, 52 projects
jeffersonlam
356
21k
AI: The stuff that nobody shows you
jnunemaker
PRO
8
750
Making the Leap to Tech Lead
cromwellryan
135
9.9k
Dominate Local Search Results - an insider guide to GBP, reviews, and Local SEO
greggifford
PRO
0
200
Building a A Zero-Code AI SEO Workflow
portentint
PRO
0
610
RailsConf & Balkan Ruby 2019: The Past, Present, and Future of Rails at GitHub
eileencodes
141
35k
Building Adaptive Systems
keathley
44
3.1k
Beyond borders and beyond the search box: How to win the global "messy middle" with AI-driven SEO
davidcarrasco
3
170
Claude Code どこまでも/ Claude Code Everywhere
nwiizo
65
56k
Efficient Content Optimization with Google Search Console & Apps Script
katarinadahlin
PRO
1
640
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