Day 31 - Redux vs XState (英文原文改作)

本篇主要论述源自於 XState 作者本人在 stackoverflow 的解释，并辅以一点我的补充。

Redux 比较像作为 state 中央储存装置、容器，藉由派发 action 来决定把状态更新成什麽样子。

XState 除了作为状态储存容器之外，更专注在限制状态如何才能到下一个状态 (比如：未缴费 -> 等待出货)，必须限於缴费的事件，需在 Machine config 做出完整的描述

XState 的「状态（ State ）」更专注区分主体实际的状况 或条件 ( condition )以及资料 Data ( context or extended state ) ，以水为例，水的状态有三种（三态：固、液、气），而水量是资料可能是 0 到 无限

Redux 的「状态（ State ）」则没被限定，可以是以上两者其一或混和，可以同时有状态跟资料，也可以单独是状态或资料

Redux 的 Reducer function 可以把它想像成是 一个只要 参数是(state, action) 并且会回传 state 的任意 function，官方并没有限制如何实作。

XState 的 Machine Config ，还记得我们之前有自己手刻一个状态机，其实他可以用双层的 switch case 实作，他着重在 状态 + 事件 组成的转移，可以把 XState 想像成是有更多规则限制的 Reducer function，还另外提供像是阶层、平行式状态、Guard、onEntry、onExit 等。

Redux 官方目前未提供 处理 side effect 内建的方法，必须藉由第三方像是 redux-observable, redux-thunk, redux-saga 等。

XState 内建并提供更细致的操作方法，让 side effect 的使用更具描述性（Declarative）、更清晰明确（Explicit），像是 entry: ['notifyActive', 'sendToast'], exit: ['notifyInactive', 'sendToast']

XState 在描述 行为、逻辑是比较明说的，可以轻易将 JSON object config 画出状态图，并从状态图看出主体的行为 " onXXX -> target:OOO (onPay -> target:'paid')"

Redux 相较之下在描述行为、逻辑是较为隐晦的，必须去阅读 swtich / case 返回的夹杂着资料和状态的 nextState。（不过 Redux 现在也可以透过 JSON object 来描述 reducer 了，可读性有比较提升）

Redux 官方目前没有提供工具来视觉化呈现 状态与状态 间的转移；XState 目前有提供，正因为 FSM 具有可描述（Declarative）的特性，使其得以较容易实现。

Redux 必须藉由开发者手动特意排除不可能存在的状态（比如说：input 元件不可能有 unchanged + invalid 的状态存在，但却要靠开发者特意过滤两个 boolean flag 中无效的逻辑）

XState 因为 StateCharts 需定义 Event 之後要转移的状态，自然而然的排除了不可能存在的状态，而且也比较能在开发前进行静态规划跟分析。

在延续新功能、新需求的进入时，只要重新规划状态图的 事件 及 转移，也避免了 违反 「开放封闭原则」可以见 Day1 和 Day2

Redux 鼓励将 State 全部中央储存，在单一 Global 集中控管（虽然我们现在也可以透过 许多 slice, dynamic module 动态载入，但仍集中於一个 store 内）

XState 鼓励以 Actor Model 的形式，让 instance 可以各自储存自己的状态，但又可以彼此互相沟通（像是之前提到的阶层式、父子状态机 TODO LIST 跟 TODO ITEM 是各自独立的状态机，但又能彼此互相沟通）

参考资料

https://stackoverflow.com/questions/54482695/what-is-an-actual-difference-between-redux-and-a-state-machine-e-g-xstate