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
複雑なコンポーネントで 状態をもつのをやめた話
Search
Daisuke Mino
July 31, 2020
Programming
0
110
複雑なコンポーネントで 状態をもつのをやめた話
Daisuke Mino
July 31, 2020
Tweet
Share
More Decks by Daisuke Mino
See All by Daisuke Mino
io.Writerで学ぶGoのインターフェース
minodisk
0
220
Goのエラーハンドリング
minodisk
0
180
Yet another side effect layer for Redux
minodisk
2
2.6k
Other Decks in Programming
See All in Programming
Site Reliability Engineering for GMO
pyama86
6
980
SwiftUIで使いやすいToastの作り方 / How to build a Toast system which is easy to use in SwiftUI
lovee
3
100
try! Swift Tokyo 初参加報告LT
hinakko2
0
190
Build with AI 2024 Seoul - 제로부터 시작하는 Flutter with Gemini 생활 - 박제창
itsmedreamwalker
0
200
Designing for tomorrow's programming workflows
honnibal
PRO
2
110
Git Lint
bkuhlmann
4
740
甘い香りに誘われてVanilla Extractを1年間運用してみた
miyahkun
1
110
Ruby Function Composition
bkuhlmann
1
330
スクラムガイドのスプリントレトロスペクティブを改めて読みかえしてみた / Re-reading the Sprint Retrospective Section in the Scrum Guide
mackey0225
3
330
PHP8.3の機能を振り返る / Review of PHP 8.3 features
seike460
PRO
1
110
Semantic search with Django and pgvector
pauloxnet
0
240
StoreKit2によるiOSのアプリ内課金のリニューアル
kangnux
0
100
Featured
See All Featured
The Illustrated Children's Guide to Kubernetes
chrisshort
29
46k
Unsuck your backbone
ammeep
662
57k
Building a Modern Day E-commerce SEO Strategy
aleyda
16
6.4k
Intergalactic Javascript Robots from Outer Space
tanoku
266
26k
Testing 201, or: Great Expectations
jmmastey
27
6.3k
How to Create Impact in a Changing Tech Landscape [PerfNow 2023]
tammyeverts
12
1.5k
The Invisible Side of Design
smashingmag
294
49k
Building Adaptive Systems
keathley
30
1.8k
A Tale of Four Properties
chriscoyier
150
22k
Designing the Hi-DPI Web
ddemaree
276
33k
The Brand Is Dead. Long Live the Brand.
mthomps
48
28k
Art, The Web, and Tiny UX
lynnandtonic
288
19k
Transcript
複雑なコンポーネントで 状態をもつのをやめた話 PrAha x Resily 勉強会 vol.1 Daisuke Mino
複雑なコンポーネント構成での お話です
状態、 どこにもたせてますか?
Objectの中? data = [{ id: 1, visible: true, }, {
id: 2, visible: false, }]
やばい(やばい)
やばいポイント1 例えば `isDragging` , `isHover` , `isScrolling` のような、ユーザー入力 によって状態が目まぐるしく変わるような状態を、複雑なコンポーネントを操作 する場合においては、状態を操作した場所が追いづらくなる。
コンポーネントに閉じる状態ならばコンポーネント内のstateに閉じておけばよ いが、渡されたデータの状態フィールドに変更を加えつつ他のコンポーネント に伝達する場合を想定する。
やばいポイント2 状態の変更がどのコンポーネントに影響を与えるのか、詳細にコードを見てい かないと分からない。
やばいポイント3 コンポーネントのレンダリングをメモ化する際に、与えられたデータの等価性を 比較する際に全フィールドを検査する必要がある。
データはデータ 状態は状態 で保持する
状態用のリストに状態を保持する data = [{ id: 1, }, { id: 2,
}] invisibleIds = [2]
やばくないポイント1 状態リストを操作したコードを調べていくと、どこでどのような操作がされたの か明確。
やばくないポイント2 どのコンポーネントがどの状態を参照しているか明確になった。
やばくないポイント3 メモ化されたコンポーネントを返すかどうかの判定において、データを舐める必 要がなく、状態のIDリストの内容だけを比較したらよい。
状態の他にも、 構造も別で保持する
状態 • selectedGroupIds: Set<string> • selectedUserIds: Set<string> • focusedIds: Set<string>
• invalidIds: Set<string> • disabledIds: Set<string> • intersectingIds: Set<string>
構造 • idNode: Map<string, NodeFragment> • parentChildren: Map<string, Array<string>> •
childParent: Map<string, string> • parentDescendants: Map<string, Array<string>> • childAncestors: Map<string, Array<string>> • rects: Map<string, Rect>
ただし、 複雑じゃないコンポーネント構 成では、オブジェクトに持たせ るのが明快そう
おわり