reduxとステートマシン（xstateなど）の実際の違いは何ですか？

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

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

Reduxは私たちのオプションですが、開発者の1人がステートマシンベースのライブラリ、特にxstateライブラリの使用を提案しました。

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

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

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

XStateを作成しましたが、どちらを使用するかについては説明しません。それはあなたのチームに依存します。代わりに、いくつかの重要な違いを強調してみます。

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

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

ステートマシンは、単方向のデータフローがあることを通知（強制）しません。データフローとは何の関係もありません。それは、状態変化の抑制と状態遷移に関するものです。したがって、通常、アプリケーションの一部のみがステートマシンで設計されます。これは、一部の状態変更を制約/禁止する必要があり、遷移に関心がある場合に限ります。

ステートマシンでは、何らかの理由（外部APIの依存関係など）でアプリが制約のために別の状態に移行できない状態でロックされる可能性がある場合は、それを解決する必要があることに注意してください。

ただし、状態遷移ではなく、最後のアプリの状態自体のみに関心があり、状態の制約が重要でない場合は、ステートマシンを使用せず、状態自体を直接更新することをお勧めします（状態をシングルトンクラスの更新でラップすることもできます）アクションクラス）。

一方、Reduxは単方向アーキテクチャフレームワークです。単方向アーキテクチャでは、データフローを一方向にする必要があります。Reduxでは、で始まりUser->View->(Action)->Store->Reducer->(Middleware)->Store->(State)->Viewます。ステートマシンと同様に、Reduxのミドルウェアで副作用を引き起こすことができます。必要に応じて、状態遷移を制約/禁止できます。ステートマシンとは異なり、Reduxのは、単方向のデータの流れを強制的に純粋な！レデューサー関数、不変の状態オブジェクト、単一の監視可能なアプリの状態。