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
130
複雑なコンポーネントで 状態をもつのをやめた話
Daisuke Mino
July 31, 2020
Tweet
Share
More Decks by Daisuke Mino
See All by Daisuke Mino
io.Writerで学ぶGoのインターフェース
minodisk
0
240
Goのエラーハンドリング
minodisk
0
200
Yet another side effect layer for Redux
minodisk
2
2.8k
Other Decks in Programming
See All in Programming
AIと私たちの学習の変化を考える - Claude Codeの学習モードを例に
azukiazusa1
10
4.2k
Design Foundational Data Engineering Observability
sucitw
3
200
時間軸から考えるTerraformを使う理由と留意点
fufuhu
16
4.8k
知っているようで知らない"rails new"の世界 / The World of "rails new" You Think You Know but Don't
luccafort
PRO
1
160
さようなら Date。 ようこそTemporal! 3年間先行利用して得られた知見の共有
8beeeaaat
3
1.4k
Namespace and Its Future
tagomoris
6
700
Ruby Parser progress report 2025
yui_knk
1
440
Reading Rails 1.0 Source Code
okuramasafumi
0
230
go test -json そして testing.T.Attr / Kyoto.go #63
utgwkk
3
300
詳解!defer panic recover のしくみ / Understanding defer, panic, and recover
convto
0
240
アプリの "かわいい" を支えるアニメーションツールRiveについて
uetyo
0
270
複雑なフォームに立ち向かう Next.js の技術選定
macchiitaka
2
130
Featured
See All Featured
Fight the Zombie Pattern Library - RWD Summit 2016
marcelosomers
234
17k
Statistics for Hackers
jakevdp
799
220k
Build your cross-platform service in a week with App Engine
jlugia
231
18k
Build The Right Thing And Hit Your Dates
maggiecrowley
37
2.9k
Site-Speed That Sticks
csswizardry
10
820
Mobile First: as difficult as doing things right
swwweet
224
9.9k
個人開発の失敗を避けるイケてる考え方 / tips for indie hackers
panda_program
112
20k
Visualizing Your Data: Incorporating Mongo into Loggly Infrastructure
mongodb
48
9.7k
GraphQLとの向き合い方2022年版
quramy
49
14k
Fireside Chat
paigeccino
39
3.6k
RailsConf & Balkan Ruby 2019: The Past, Present, and Future of Rails at GitHub
eileencodes
139
34k
The MySQL Ecosystem @ GitHub 2015
samlambert
251
13k
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>
ただし、 複雑じゃないコンポーネント構 成では、オブジェクトに持たせ るのが明快そう
おわり