Redux
https://scrapbox.io/files/64407e7f70debf001c2bc99b.png
人によっては以下でも雰囲気が伝わるかもしれない
脱MVCを目指して生まれた
理論的な話
2015年頃の記事を読むと時代背景がわかりやすい
「純粋関数適用以外での値の変更を許さない」ことを強制することによって、「処理の途中で不規則なデータ変更によって生じるバグを未然に防ぎ」、変更に冪等性があることから、「バグが発生した時に、どの順序で何の処理を行ったかという履歴を追跡することで、バグ発生時の状況を必ず再現できること、また、何を行ったことでバグが発生したのかを追跡する」こと
Redux における「参照系（があるとしたら）」とは Selector、旧くは react-redux における mapStateToProps だけを指す。action は常に更新系、CQRS の C だという発想がないと設計で混乱すると思う。 逆に言うと Redux を選択するっていうことはこの思想を受け入れるってことでもあるので、Read がメインで状態の更新が少ないケースでは、複雑度に関係なく選ばないほうが良いと思う。
reduxをCQRSとして捉える
ReduxはただのクライアントサイドCQRSだよ
CとQをドメインごとに切ると捗るよ
けど純粋な ducks パターンはきついよ
ドメインモデルはプレーンなjsonと純粋関数で持つと良いよ
難しさが廃されるのではなく、難しい部分が一箇所に集中する。React Component の末端では、何も考えることがなくなる。状態管理という難しい部分を作る人と、末端のコンポーネントのデザインに注力する人を分けられる。 大規模になっても設計が破綻しにくい、というエンタープライズ向きな特性を持つ。が、その技術基盤は(静的)関数型由来の考えが多く、基礎設計や基盤理解にはハイスキルが要求され、需要と適用対象のミスマッチを感じることはある。結果として、そもそもハイスキルを前提として、大規模であることが自明な SPA 向きということになる redux の作者でありオピニオンリーダーだった Dan Abramov は、現在 redux との距離を置いているように見える。React コアチームに近い、よりシンプルなものを、という立場になっている なんだかんだで Redux は「(REST) API から取ったモデルを View Model にする」というパラダイムの産物だと思う。 クライアントサイドの状態設計をする際は、常に「このモデルは親になることがありうるか？」「親から独立してそれ単体で一覧や詳細を取得するシチュエーションがあるか？」を自問するとよい。それがありうるモデルだけを reducer の主語にすると上手くユースケースに応じてまとまりやすい。「こいつは他のモデルのサブリソース以外にならないんじゃないか？」と思ったら json の 1 プロパティにとどめた方がよく、それは API 側も大抵そうなっているはずだ。
koushisa.icon
フロントエンドの状態管理にCQSのエッセンスで純粋性を持ち込んだ先駆者 スタイルガイドやその思想の普及、議論してきた人たちも含め大いにリスペクトしている
Reduxの本質
Reduxの問題点
例えば、ローディングの状態管理はコンポーネントのライフサイクルと密結合なので手続き的に制御するほうが都合が良かったりする
thunkやsagaなどのミドルウェアで頑張っていたが、コード量が多すぎて直感的ではなかった
@yuta0801_: ただ普通のアプリケーションだとAPIから取ってきたデータをキャッシュに保存するだけで、CRUD以外のアクションがほとんどないという… 後述
@seanchas_t: React、ドメイン→UIのマップを宣言的にできるようにしただけで、ドメイン自体の管理にはOOPが必須だと思ってる 同じ時間軸で別のReducerを同時に更新したい場合はどうする？
コンポーネントのprops制御で完結できるものも含めて全てのロジックをReduxに乗せる アコーディオン開閉状態みたいな本質的にはUI Stateに分類できるものまで紛れ込んでくる 分割しないとfat model化
どこで何が起きてるかわからなくなり、無法地帯になっていく
疎結合であるが故に追うのも難しく、コードを削除するのが恐くなる 分割すればするほどdispatchは複雑になる
求められる知識量と経験が指数関数的に増えていく
ジュニアエンジニアや新規の参画者にとっては優しくない
一応、経験者が先導して引っ張っていけばなんとかなるものではなる
相応のリソースは取られる
限られた時間は「開発者のための設計統一」より「ユーザーにとっての価値最大化」に割きたい ジレンマが重なり、やりたいことに対し不必要に複雑な構成になっていく
特定のライブラリをReduxで使えるようにするためのAdapterみたいなのも必要になる そもそもSPAは「クライアント」なので「サーバー」のリソースを変化させる副作用や非同期処理が主である 状態遷移を疎結合にする旨味よりも、冗長性や全体像を掴みづらいデメリットのほうが高くつく 一般的なアプリケーションではReduxはオーバーキルだった
たとえReduxを使ったとしてもフロントエンドの本質的な難しさは解決できていない
コードとしての複雑さがあるときにトップダウンで分割すると、本質的な難しさは解決せず隠蔽されているだけのことが多いように思う
ここからボトムアップに状態管理する方法が主流になった コンポーネントの純粋性が高まってより高凝集になった HTTPリクエストのロード状態なんか
const { loading } = useQuery(...);
で今どきは済むところをusecase->port->presenterとかやる意味ンゴ…😇
「FacebookはReduxは使っていないがFluxは使っている」と昔だれかが言ってた(覚えていない)
中央集権から脱却した分散型のボトムアップ方式
そして2023年
5年後ぐらいにこの文脈で、コンポーネントの遅延束縛手段として再登場するんじゃないかと期待している