2015年7月**：目前最有前途的基于不变性的框架是Redux！2看一下！3它不像Om那样使用游标（Om Next也不使用游标）。
光标并不是真正可扩展的，尽管使用了下文所述的CQRS原理，但它仍然在组件中创建了太多的样板文件，这很难维护，并且当你想在现有应用程序中移动组件时会增加摩擦。
此外，对于许多开发人员来说，何时使用和不使用光标并不清楚，我看到开发人员在不应该使用光标的地方使用光标，这使得组件的可重用性低于使用简单 prop 的组件。
Redux使用connect()，并清楚地解释了何时使用它（容器组件），何时不使用它（无状态/可重用组件），它解决了沿树向下传递游标的样板问题，并且在没有太多妥协的情况下执行得很好。
我在这里介绍了不使用connect()的缺点
尽管不再使用游标，我的答案的大部分仍然有效
我自己在我们的启动内部框架**atom-react**中做过
JS中的一些备选项是Morearty、React-cursors、Omniscient或Baobab
那时还没有immutable-js，我也没有做迁移，仍然使用普通的JS对象（冻结）。
我不认为使用持久化数据结构库是真的需要，除非你有非常大的列表，你经常修改/复制。当你注意到性能问题时，你可以使用这些项目作为优化，但它似乎不需要实现OM的概念来利用shouldComponentUpdate。一件有趣的事情是immutable-js中关于批量变异的部分。但无论如何，我仍然认为这是优化，并不是一个核心的先决条件，有非常体面的表现与React使用OM的概念。
您可以在这里找到我们的开源代码：
它有Clojurescript Atom的概念，这是一个不可变对象（用DeepFreeze冻结）的可交换引用。它也有事务的概念，以防你想原子地更新状态的多个部分。你可以监听Atom的变化（事务结束）来触发React呈现。
它有cursor的概念，就像Om中的一样（像一个功能透镜）。它允许组件能够呈现状态，但也可以很容易地修改它。这对于表单来说很方便，因为你可以直接链接到光标进行双向数据绑定：

<input type="text" valueLink={this.linkCursor(myCursor)}/>

它有纯渲染的概念，开箱即用优化，就像在Om中一样
与Om的差异：

*无本地状态（禁止此.setState（o））

在Atom-React组件中，您不能拥有本地组件状态。**所有状态都存储在React之外。**除非您需要集成现有的Js库（您仍然可以使用常规的React类），将所有状态存储在Atom中（即使是异步/加载值）和整个应用程序从主React组件重新呈现自己。React然后只是一个模板引擎，非常高效，它可以将JSON状态转换为DOM。我发现这非常方便，因为我可以在每次呈现时记录当前Atom状态，然后调试呈现代码非常容易。由于shouldComponentUpdate开箱即用，它速度足够快，以至于每当用户在文本输入时按下新的键盘键，或用鼠标悬停按钮时，我甚至可以重新呈现整个应用程序。甚至在移动的上也是如此！

*管理状态的个人方法（受CQRS/EventSourcing和Flux启发）

受Flux和CQRS的启发，Atom-React有一种非常固执己见的方式来管理状态。一旦您将所有状态都置于React之外，并且您有了一种将JSON状态转换为DOM的有效方法，您将发现剩下的困难是管理JSON状态。
遇到的一些困难是：
1.如何处理异步值
1.如何处理需要DOM更改的视觉效果（例如鼠标悬停或聚焦）
1.如何组织你的州，使其成为一个庞大的团队
1.在哪里触发 AJAX 请求。
最后，我提出了Store的概念，这是受Facebook Flux architecture的启发。关键是，我真的不喜欢这样一个事实，即一个Flux存储实际上可以依赖于另一个存储，需要通过一个复杂的调度器来编排操作。最终，您必须了解多个存储的状态，才能呈现它们。
在Atom-React中，Store只是Atom持有的状态中的一个“保留名称空间”。

所以我更喜欢所有的存储都从应用程序中发生的事件流中更新。每个存储都是独立的，并且不访问其他存储的数据（与CQRS体系结构中完全一样，其中组件接收完全相同的事件，被托管在不同的机器中，并且如他们想要的那样管理他们自己的状态）。这使得它更容易维护，因为当您开发一个新组件时，您只需要了解一个存储的状态。这在某种程度上会导致数据重复，因为现在在某些情况下，多个存储区可能必须保留相同的数据（例如，在SPA上，很可能您希望当前用户ID出现在应用程序的多个位置）。但如果2个商店将同一对象置于其状态（来自事件）这实际上不消耗任何额外的数据，因为这仍然是1个对象，在2个不同的存储中引用了两次。
要了解这一选择背后的原因，您可以阅读CQRS领导者Udi Dahan、The Fallacy Of ReUse和其他人关于自主元件的博客文章。
因此，存储只是接收事件并更新Atom中其命名空间状态的一段代码。
这就把状态管理的复杂性转移到了另一层，现在最难的是精确地定义哪些是应用程序事件。
请注意，这个项目仍然非常不稳定，没有文档记录/没有很好的测试。但是我们已经在这里使用它并取得了巨大的成功。如果你想讨论它或贡献，你可以在IRC上找到我：x一米六氮一x在x一米七氮一x中。
这就是使用此框架开发SPA的感觉。每次使用调试模式呈现SPA时，您都有：

• 将JSON转换为虚拟DOM并将其应用于真实的DOM所花费的时间。
• 记录状态以帮助您调试应用
• 由于React.addons.Perf而浪费了时间
• 与先前状态相比的路径差异，以便轻松了解发生了哪些更改

查看此屏幕截图：

这种框架可以带来的一些优势我还没有深入探讨：

• 你真的有内置的撤销/重做（这在我真正的生产应用程序中是开箱即用的，而不仅仅是TodoMVC）。然而，恕我直言，许多应用程序中的大多数操作实际上都在服务器上产生副作用，所以将UI反转到以前的状态并不总是有意义的，因为以前的状态会过时
• 您可以记录状态快照，并在另一个浏览器中加载它们。CircleCI已经在this video上演示了这一点
• 您可以用JSON格式记录用户会话的“视频”，将它们发送到后端服务器进行调试或重放视频。您可以将用户会话实时传输到另一个浏览器以获得用户帮助（或者监视用户的实时用户体验行为）发送状态可能会非常昂贵，但可能像Avro这样的格式会有所帮助。或者，如果你的应用事件流是可序列化的，你可以简单地流传输这些事件。我已经在框架中很容易地实现了它，它在我的生产应用程序中也能工作（只是为了好玩，它还没有向后端传输任何东西）
• 时间旅行调试可以像在ELM中一样成为可能

我为感兴趣的人制作了a video of the "record user session in JSON" feature。

你可以有OM一样的应用程序状态，没有另一个React Package 器，并与纯通量-检查它在这里https://github.com/steida/este这是我非常完整的React初学者工具包。