Reactの状態管理の変遷に関する記事を読んだ
Reactの状態管理の変遷に関する自分史 From 2014 To 2022
読んだ。
React、全然終えてないので少しでもこういうまとめっぽい感じで簡潔なのがあるとありがたい。
自分はHooksが出てちょっとしたくらいのところまでReactを触っていた。この記事でいう、Presentational/Containerでコンポーネントを分け、Storeからの情報をpropsのリレーで渡すというのがのが自分の中での「当たり前」のような感じ。
Hooksが出てuseStateやuseEffectを使うようになって少し経ったくらいでVue/Nuxtに移った。
現在はVue/Nuxtでの状態の持ち方や置き方に悩んでいるところであるけれど、React/Nextでもたぶん同じような感じなんだろうなという気持ち。
記事によれば、Colocation/Lifting State Upという指針を公式が出しているらしい。
表示のためのデータ取得と描画をできるかぎり近くによせて管理する、必要に応じてStoreの場所を上位に移動したり、ContextやGlobalなStoreに移動する
ふむふむ。
React アプリケーションで変化するどのようなデータも単一の “信頼出来る情報源” であるべきです。通常、state はレンダー時にそれを必要とするコンポーネントに最初に追加されます。それから、他のコンポーネントもその state を必要としているなら、直近の共通祖先コンポーネントにその state をリフトアップすることができます。異なるコンポーネント間で state を同期しようとする代わりに、トップダウン型のデータフローの力を借りるべきです。
state のリフトアップは双方向のバインディング (two-way binding) を行う方法より多くの “ボイラープレート” コードを生み出しますが、その効果としてバグを発見して切り出す作業が少なく済むようになります。あらゆる state はいずれかのコンポーネント内に存在し、そのコンポーネントのみがその state を変更できるので、バグが潜む範囲は大幅に削減されます。加えて、ユーザ入力を拒否したり変換したりする任意の独自ロジックを実装することもできます。
とにかく必要なデータは使う場所の近くに置き、もしそのデータが他の場所でも使う必要がある場合は上位に定義し直しpropsで渡すようにする、ということかな。
双方向バインディングよりこっちのほうが好きなので、こういう感じでやっていきたいなあ。