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
250
Goのエラーハンドリング
minodisk
0
200
Yet another side effect layer for Redux
minodisk
2
2.8k
Other Decks in Programming
See All in Programming
iOSエンジニア向けの英語学習アプリを作る!
yukawashouhei
0
200
When Dependencies Fail: Building Antifragile Applications in a Fragile World
selcukusta
0
100
Cursorハンズオン実践!
eltociear
2
1.1k
なぜあの開発者はDevRelに伴走し続けるのか / Why Does That Developer Keep Running Alongside DevRel?
nrslib
3
410
AIと人間の共創開発!OSSで試行錯誤した開発スタイル
mae616
2
720
実践Claude Code:20の失敗から学ぶAIペアプログラミング
takedatakashi
15
6k
私達はmodernize packageに夢を見るか feat. go/analysis, go/ast / Go Conference 2025
kaorumuta
2
600
Six and a half ridiculous things to do with Quarkus
hollycummins
0
180
Go言語はstack overflowの夢を見るか?
logica0419
0
460
CSC305 Lecture 06
javiergs
PRO
0
250
開発生産性を上げるための生成AI活用術
starfish719
3
1.4k
ALL CODE BASE ARE BELONG TO STUDY
uzulla
25
6.4k
Featured
See All Featured
Designing Experiences People Love
moore
142
24k
Building a Modern Day E-commerce SEO Strategy
aleyda
44
7.8k
Build your cross-platform service in a week with App Engine
jlugia
232
18k
Raft: Consensus for Rubyists
vanstee
140
7.1k
Large-scale JavaScript Application Architecture
addyosmani
514
110k
How to train your dragon (web standard)
notwaldorf
97
6.3k
Into the Great Unknown - MozCon
thekraken
40
2.1k
Building an army of robots
kneath
306
46k
Connecting the Dots Between Site Speed, User Experience & Your Business [WebExpo 2025]
tammyeverts
10
600
Why Our Code Smells
bkeepers
PRO
340
57k
Being A Developer After 40
akosma
91
590k
Save Time (by Creating Custom Rails Generators)
garrettdimon
PRO
32
1.6k
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>
ただし、 複雑じゃないコンポーネント構 成では、オブジェクトに持たせ るのが明快そう
おわり