複雑なコンポーネントで 状態をもつのをやめた話 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 ● selectedUserIds: Set ● focusedIds: Set ● invalidIds: Set ● disabledIds: Set ● intersectingIds: Set

構造 ● idNode: Map ● parentChildren: Map> ● childParent: Map ● parentDescendants: Map> ● childAncestors: Map> ● rects: Map

ただし、 複雑じゃないコンポーネント構 成では、オブジェクトに持たせ るのが明快そう

おわり