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
Sponsored
·
SiteGround - Reliable hosting with speed, security, and support you can count on.
→
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
MDN Web Docs に日本語翻訳でコントリビュート
ohmori_yusuke
0
660
MUSUBIXとは
nahisaho
0
140
プロダクトオーナーから見たSOC2 _SOC2ゆるミートアップ#2
kekekenta
0
230
360° Signals in Angular: Signal Forms with SignalStore & Resources @ngLondon 01/2026
manfredsteyer
PRO
0
140
CSC307 Lecture 03
javiergs
PRO
1
490
CSC307 Lecture 05
javiergs
PRO
0
500
AWS re:Invent 2025参加 直前 Seattle-Tacoma Airport(SEA)におけるハードウェア紛失インシデントLT
tetutetu214
2
120
Apache Iceberg V3 and migration to V3
tomtanaka
0
170
CSC307 Lecture 04
javiergs
PRO
0
660
OCaml 5でモダンな並列プログラミングを Enjoyしよう!
haochenx
0
150
CSC307 Lecture 08
javiergs
PRO
0
670
[KNOTS 2026登壇資料]AIで拡張‧交差する プロダクト開発のプロセス および携わるメンバーの役割
hisatake
0
300
Featured
See All Featured
What Being in a Rock Band Can Teach Us About Real World SEO
427marketing
0
180
DevOps and Value Stream Thinking: Enabling flow, efficiency and business value
helenjbeal
1
110
Measuring & Analyzing Core Web Vitals
bluesmoon
9
760
Sharpening the Axe: The Primacy of Toolmaking
bcantrill
46
2.7k
Producing Creativity
orderedlist
PRO
348
40k
Designing for Timeless Needs
cassininazir
0
130
Heart Work Chapter 1 - Part 1
lfama
PRO
5
35k
Unsuck your backbone
ammeep
671
58k
The browser strikes back
jonoalderson
0
420
The Impact of AI in SEO - AI Overviews June 2024 Edition
aleyda
5
740
Have SEOs Ruined the Internet? - User Awareness of SEO in 2025
akashhashmi
0
270
Building Experiences: Design Systems, User Experience, and Full Site Editing
marktimemedia
0
410
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>
ただし、 複雑じゃないコンポーネント構 成では、オブジェクトに持たせ るのが明快そう
おわり