unstated-next による Redux に頼らない状態管理の考察

unstated-next による Redux に頼らない状態管理の考察

React.kyoto v0.3.0 でのLT発表資料です。
https://react-kyoto.connpass.com/event/137847/

790f55ccde7a62df8f25747586657090?s=128

Yoshihide Jimbo

July 19, 2019
Tweet

Transcript

  1. 3.
  2. 7.

    Hooks の登場によって、 Redux などの「状態管理ライブラリ」に頼らず、 React の Context と Hooks だけで状態管理を実装することが

    可能になった。
 
 unstated-next はその実装をサポートしてくれる、
 必要最⼩限なライブラリ(わずか 200バイト)
  3. 8.

    unstated-next と unstated の関係 • unstated というライブラリもあってちょっとややこしい。 • 開発者はどちらも @jamiebuilds

    ⽒。 • unstated は Context を活⽤したシンプルな状態管理ライブラリ。
 2018年前半に発表された。 • その後、React から Hooks がリリースされ、unstated のコンセプトをよりコン パクトに実現できるようになったため、Hooks ベースの API に⼀新して unstated-next という別パッケージで 2019年5⽉にリリースされた。
  4. 23.

    Redux よりも優れている点 • ファイルサイズは 1/40 • 学習コストが圧倒的に低い(Context と Hooks さえ知っていればいい)

    • ほぼ素の React なので、どんなライブラリとも連携しやすい • パフォーマンスの⾯でも有利
  5. 24.

    Redux よりも優れている点 • ファイルサイズは 1/40 • 学習コストが圧倒的に低い(Context と Hooks さえ知っていればいい)

    • ほぼ素の React なので、どんなライブラリとも連携しやすい • パフォーマンスの⾯でも有利 ← どういうことか?
  6. 25.

    Redux Store container component container component container component container component

    Redux では、State が更新されると、マウント中の すべての Container Component(Store とつながっているコンポーネント)が、変更の通知を受けとって、 mapStateToProps(ある いは useSelector) を実⾏する mapStateToProps() mapStateToProps() mapStateToProps() mapStateToProps()
  7. 26.

    Redux Store container component container component container component container component

    処理の遅い mapState が1つ存在していると、state が変更されるたびに毎回実⾏されるため、 アプリケーション全体のパフォーマンスを落とす重⼤なボトルネックとなる。 mapStateToProps() mapStateToProps() mapStateToProps() mapStateToProps()
  8. 27.

    Redux Store container component container component container component container component

    「⽬に⾒えて遅くはないが、微妙に遅い」という mapState でも、たくさん存在すると、 やはりパフォーマンス劣化の要因となってくる。 mapStateToProps() mapStateToProps() mapStateToProps() mapStateToProps()
  9. 29.

    component component component component component container container container container 次のように、Container

    (≒ Store) を複数に分けて、コンポーネントが本当に必要としている 場合だけ共有するようになっていれば、この問題は避けられる。
  10. 31.

    unstated-next では、
 Redux のようにアプリケーション全体の State を ⼀つの巨⼤な Container で管理するのではなく、 適切な粒度に分割して管理することが推奨されている。

    ただし、Container の粒度に関する制約やルールは
 存在していないので、⾃分でルールを決めて運⽤する必要がある。
  11. 35.

    Redux で Store を複数に分割すればいいのでは? • Redux の FAQ に回答が載っている。
 可能は可能だけど、Redux

    DevTools とか使えなくなるし、単⼀の Store で使ってもらうことを想定している、とのこと。
 
 https://redux.js.org/faq/store-setup#can-or-should-i-create-multiple- stores-can-i-import-my-store-directly-and-use-it-in-components- myself
  12. 38.

    最適化のコツは? • Redux での「reselectを使いましょう」的な、unstated-next ならではの 最適化テクニックは特にない。 • 素の React とほぼ同じなので、React

    のスタンダードな最適化がそのまま 使える。
 https://github.com/jamiebuilds/unstated-next#tip-3-optimizing- components
  13. 39.

    デバッグはどうする? • 専⽤のデバッグツールはない。 • React Developer Tools に Hooks のサポートが⼊っていて、最新の

    state の値は確認できるが、変更履歴などは確認できない。
 https://github.com/facebook/react-devtools/pull/1272 • これが⼀番つらいところかも。
  14. 40.

    今すぐ Redux を捨てて unstated-next に乗り換えるべきか? • Redux よりも簡単にコーディングできるのは間違いないが、Redux とは 別の全体設計⼒が試される。

    • 既存のアプリケーションに導⼊するのであれば、パフォーマンスチューニ ングの⼀環として、書き換えが頻発する State の⼀部を unstated-next に 置き換えてみるのはありだと思う。
  15. 42.

    スケールするのか?(⼤規模アプリでも使えるか?) • Container はクリーンアーキテクチャの Presenter(ユースケースやエンティティのデータ 形式を変換して、外界である UI に伝える役割)に あたるように思うが、React にがっつり依存して

    いるのでこのレイヤーなのか少しモヤモヤする。 • クリーンアーキテクチャに適⽤するなら unstated-next ではなく unstated のほうが
 ぴったりはまりそうな印象。
  16. 44.