複雑なコンポーネントで 状態をもつのをやめた話

Transcript

1. 複雑なコンポーネントで 状態をもつのをやめた話 PrAha x Resily 勉強会 vol.1 Daisuke Mino
2. 複雑なコンポーネント構成での お話です
3. 状態、 どこにもたせてますか？
4. Objectの中？ data = [{ id: 1, visible: true, }, { id: 2, visible: false, }]
5. やばい（やばい）
6. やばいポイント1 例えば `isDragging` , `isHover` , `isScrolling` のような、ユーザー入力 によって状態が目まぐるしく変わるような状態を、複雑なコンポーネントを操作 する場合においては、状態を操作した場所が追いづらくなる。 コンポーネントに閉じる状態ならばコンポーネント内のstateに閉じておけばよ いが、渡されたデータの状態フィールドに変更を加えつつ他のコンポーネント に伝達する場合を想定する。
7. やばいポイント2 状態の変更がどのコンポーネントに影響を与えるのか、詳細にコードを見てい かないと分からない。
8. やばいポイント3 コンポーネントのレンダリングをメモ化する際に、与えられたデータの等価性を 比較する際に全フィールドを検査する必要がある。
9. データはデータ 状態は状態 で保持する
10. 状態用のリストに状態を保持する data = [{ id: 1, }, { id: 2, }] invisibleIds = [2]
11. やばくないポイント1 状態リストを操作したコードを調べていくと、どこでどのような操作がされたの か明確。
12. やばくないポイント2 どのコンポーネントがどの状態を参照しているか明確になった。
13. やばくないポイント3 メモ化されたコンポーネントを返すかどうかの判定において、データを舐める必 要がなく、状態のIDリストの内容だけを比較したらよい。
14. 状態の他にも、 構造も別で保持する
15. 状態 • selectedGroupIds: Set<string> • selectedUserIds: Set<string> • focusedIds: Set<string> • invalidIds: Set<string> • disabledIds: Set<string> • intersectingIds: Set<string>
16. 構造 • 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>
17. ただし、 複雑じゃないコンポーネント構 成では、オブジェクトに持たせ るのが明快そう
18. おわり