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
120
複雑なコンポーネントで 状態をもつのをやめた話
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
190
Yet another side effect layer for Redux
minodisk
2
2.7k
Other Decks in Programming
See All in Programming
Lottieアニメーションをカスタマイズしてみた
tahia910
0
130
データベースのオペレーターであるCloudNativePGがStatefulSetを使わない理由に迫る
nnaka2992
0
200
コミュニティ駆動 AWS CDK ライブラリ「Open Constructs Library」 / community-cdk-library
gotok365
2
170
Visual StudioのGitHub Copilotでいろいろやってみる
tomokusaba
1
180
Pulsar2 を雰囲気で使ってみよう
anoken
0
240
もう僕は OpenAPI を書きたくない
sgash708
5
1.8k
密集、ドキュメントのコロケーション with AWS Lambda
satoshi256kbyte
0
200
ソフトウェアエンジニアの成長
masuda220
PRO
12
2k
ARA Ansible for the teams
kksat
0
150
PRレビューのお供にDanger
stoticdev
1
190
法律の脱レガシーに学ぶフロントエンド刷新
oguemon
5
740
Domain-Driven Transformation
hschwentner
2
1.9k
Featured
See All Featured
A better future with KSS
kneath
238
17k
Save Time (by Creating Custom Rails Generators)
garrettdimon
PRO
29
1k
Making the Leap to Tech Lead
cromwellryan
133
9.1k
Building Applications with DynamoDB
mza
93
6.2k
How to train your dragon (web standard)
notwaldorf
91
5.8k
Improving Core Web Vitals using Speculation Rules API
sergeychernyshev
9
490
Automating Front-end Workflow
addyosmani
1368
200k
The Power of CSS Pseudo Elements
geoffreycrofte
75
5.5k
How to Ace a Technical Interview
jacobian
276
23k
No one is an island. Learnings from fostering a developers community.
thoeni
21
3.1k
A Tale of Four Properties
chriscoyier
158
23k
CoffeeScript is Beautiful & I Never Want to Write Plain JavaScript Again
sstephenson
160
15k
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>
ただし、 複雑じゃないコンポーネント構 成では、オブジェクトに持たせ るのが明快そう
おわり