redux とステートマシン (例: xstate) の実際の違いは何ですか? 質問する

redux とステートマシン (例: xstate) の実際の違いは何ですか? 質問する

私は、中程度の複雑さを持つフロントエンド アプリケーションの調査に取り組んでいます。現時点では、純粋な JavaScript で記述されており、アプリケーションのいくつかの主要部分を接続するさまざまなイベント ベースのメッセージが多数あります。

私たちは、さらなるリファクタリングの範囲内で、このアプリケーションに何らかの状態コンテナを実装する必要があると判断しました。以前、私は redux と ngrx ストア (実際には同じ原則に従います) の経験がありました。

戻ってきた私たちにとっては選択肢の一つですが、開発者の一人がステートマシンベースのライブラリ、特にxstate ライブラリ

私は xstate を使ったことがなかったので、興味深いと思い、ドキュメントを読み、さまざまな例を調べ始めました。有望で強力に見えましたが、ある時点で、xstate と redux の間に大きな違いはないことがわかりました。

私は何時間もかけて答えや、xstateとreduxを比較する他の情報を探しました。いくつかの記事を除いて、明確な情報は見つかりませんでした。「Redux からステートマシンへ」、またはreduxとxstateの使用に焦点を当てたライブラリへのリンク一緒に(かなり奇妙です)。

誰かがその違いを説明したり、開発者が xstate を選択すべき状況について教えてくれたら、大歓迎です。

ベストアンサー1

私は XState を作成しましたが、どちらを使用するべきかについては説明しません。それはチーム次第です。その代わりに、いくつかの重要な違いを強調したいと思います。

戻ってきた Xステート
本質的にはイベント(行動Reduxでは、状態を更新するリデューサーに送られる。 状態コンテナでもあるが、有限状態(例、"loading""success"を「無限状態」またはコンテキスト(例、items: [...])から分離する。
リデューサーの定義方法は規定されていません。リデューサーは現在の状態とイベント(アクション)に基づいて次の状態を返す単純な関数です。 「ルール付きリデューサー」 - イベントによる有限状態間の正当な遷移と、遷移時に(または状態の開始/終了時に)実行されるアクションを定義します。
するない副作用を処理するための組み込みの方法があります。redux-thunk、redux-saga など、コミュニティのオプションが多数あります。 アクション(副作用)を宣言的かつ明示的にします。これらは、State各遷移(現在の状態 + イベント)で返されるオブジェクトの一部です。
現時点では有限状態と無限状態を区別できないため、状態間の遷移を視覚化する方法がない。 ビジュアライザーがあります:https://statecharts.github.io/xstate-vizこれは宣言的な性質により実現可能である
リデューサーで表現される暗黙のロジック/動作は、宣言的にシリアル化できない(例:JSON) ロジック/動作を表すマシン定義はJSONにシリアル化でき、JSONから読み取ることができるため、動作の移植性が高く、外部ツールで構成可能になる。
厳密にはステートマシンではない W3C SCXML仕様に厳密に準拠しています。https://www.w3.org/TR/scxml/
不可能な状態を手動で防ぐために開発者に依存する ステートチャートを使用してイベント処理の境界を自然に定義し、不可能な状態を防ぎ、静的に分析できるようにします。
単一の「グローバル」アトミックストアの使用を推奨する アクターモデルのようなアプローチの使用を推奨します。このアプローチでは、相互に通信する階層的なステートチャート/「サービス」インスタンスが多数存在する可能性があります。

今週、ドキュメントにさらに重要な違いを追加します。

おすすめ記事