Om但是在javascript中

Question

我将成为David Nolen的Om库的粉丝.

我想在我们的团队中构建一个不太大的Web应用程序,但我无法说服我的队友切换到ClojureScript.

有没有办法可以使用om中使用的原则但是在JavaScript中构建应用程序？

我想的是:

1. 不可变数据结构的immutable-js或mori
2. CSP的js-csp
3. 只是app-state原子的普通javascript对象
4. 游标的immutable-js
5. 用于跟踪app-state和发送游标通知的东西

我正在努力争取上面的第5名.

有没有人冒险进入这个领域或有任何建议？也许有人尝试使用immutable-js构建react.js应用程序？

Answer 1

编辑2015年7月:目前最有前途的基于不变性的框架是Redux!看一看!它不使用Om之类的游标(Om Next也不使用游标).

尽管使用了下面描述的CQRS原理,游标仍然不具备可扩展性,但它仍然会在组件中创建太多样板,难以维护,并且当您想要在现有应用程序中移动组件时会增加摩擦力.

此外,许多开发人员不清楚何时使用和不使用游标,并且我看到使用游标的开发人员不应该使用游标,这使得组件可以重复使用简单道具的组件.

Redux使用connect()并清楚地解释何时使用它(容器组件),何时不使用(无状态/可重用组件).它解决了将游标向下传递到树上的样板问题,并且在没有太多妥协的情况下执行得非常好.

我写过关于不使用这里的缺点connect()

尽管不再使用游标,但我的答案的大多数部分仍然有效恕我直言

我已经在我们的启动内部框架中完成了原子反应

JS中的一些替代品是Morearty,React-cursors,Omniscient或Baobab

当时还没有immutable-js,我没有进行迁移,仍然使用普通的JS对象(冻结).

我不认为使用持久性数据结构lib是非常必要的,除非你有经常修改/复制的非常大的列表.当您将性能问题视为优化时,可以使用这些项目,但似乎并不需要实现Om的概念来进行优化shouldComponentUpdate.可能有趣的一件事是immutable-js关于批处理突变的部分.但无论如何,我仍然认为这是优化,并不是使用Om的概念与React进行非常好的表现的核心先决条件.

你可以在这里找到我们的开源代码:

它具有Clojurescript Atom的概念,它是对不可变对象的可交换引用(使用DeepFreeze冻结).它还具有事务的概念,以防您希望以原子方式更新状态的多个部分.您可以侦听Atom更改(事务结束)以触发React呈现.

它具有光标的概念,就像在Om中一样(像功能镜头一样).它允许组件能够呈现状态,但也可以轻松地修改它.这对于表单很方便,因为您可以直接链接到游标以进行双向数据绑定:

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

它具有纯渲染的概念,开箱即用,就像在Om 中一样

与Om的不同之处:

• 没有本地状态(禁止this.setState(o))

在Atom-React组件中,您不能拥有本地组件状态.所有状态都存储在React之外.除非您有现有Js库的集成需求(您仍然可以使用常规的React类),否则将所有状态存储在Atom中(即使是异步/加载值),整个应用程序也会从主React组件中重新呈现.React只是一个非常高效的模板引擎,它将JSON状态转换为DOM.我发现这非常方便,因为我可以在每个渲染上记录当前的Atom状态,然后调试渲染代码非常简单.由于开箱即用,shouldComponentUpdate它足够快,每当用户在文本输入上按下新的键盘键,或者用鼠标悬停按钮时,我甚至可以重新呈现完整的应用程序.即使在手机上!

• 管理国家的意见方式(受CQRS/EventSourcing和Flux的启发)

Atom-React有一种非常自以为是的方式来管理受Flux和CQRS启发的状态.一旦你拥有React之外的所有状态,并且你有一种将JSON状态转换为DOM的有效方法,你会发现剩下的难点是管理你的JSON状态.

遇到的一些困难是:

1. 如何处理异步值
2. 如何处理需要更改DOM的视觉效果(鼠标悬停或焦点为例)
3. 如何组织您的状态,以便在大型团队中扩展
4. 在哪里解雇ajax请求.

所以我最终得到了Store的概念,受到了Facebook Flux架构的启发.关键是我真的不喜欢Flux商店实际上可以依赖另一个商店的事实,需要通过复杂的调度员来协调行动.并且您最终必须了解多个商店的状态才能呈现它们.

在Atom-React中,Store只是Atom所处状态内的"保留命名空间".

所以我更喜欢从应用程序中发生的事件流更新所有商店.每个商店都是独立的,并且不访问其他商店的数据(就像在CQRS架构中,组件接收完全相同的事件,托管在不同的机器中,并按照自己的意愿管理自己的状态).这使得维护更容易,因为在开发新组件时,您只需要了解一个商店的状态.这在某种程度上会导致数据重复,因为现在多个商店在某些情况下可能必须保留相同的数据(例如,在SPA上,您可能希望在应用的许多位置使用当前用户ID).但是如果2个商店将相同的对象放在他们的状态(来自事件),这实际上不消耗任何额外的数据,因为这仍然是1个对象,在2个不同的商店中引用两次.

要了解这一选择背后的原因,您可以阅读CQRS领导人Udi Dahan,The Fallacy Of ReUse和其他有关自主组件的博客文章.

因此,商店只是一段接收事件并在Atom中更新其命名空间状态的代码.

这将状态管理的复杂性转移到另一层.现在最困难的是精确定义哪些是您的应用程序事件.

请注意,此项目仍然非常不稳定且未记录/未经过充分测试.但我们已经在这里使用它取得了巨大成功.如果您想讨论或贡献,您可以通过IRC联系我:Sebastien-Lin #reactjs.

这就是用这个框架开发SPA的感觉.每次渲染时,使用调试模式,您都有:

• 将JSON转换为Virtual DOM并将其应用于真实DOM所花费的时间.
• 记录状态以帮助您调试应用程序
• 浪费时间归功于 React.addons.Perf
• 与先前状态相比的路径差异很容易知道发生了什么变化

检查此截图:

这种框架可以带来的一些优点,我还没有探索过这么多:

• 你真的有内置的undo/redo(这在我的真实制作应用程序中开箱即用,而不仅仅是TodoMVC).然而,恕我直言,许多应用程序中的大多数操作实际上都会在服务器上产生副作用,因此将UI反转到之前的状态并不总是有意义,因为之前的状态将是陈旧的

• 您可以记录状态快照,并在另一个浏览器中加载它们.CircleCI已经在此视频中展示了这一点

• 您可以以JSON格式记录用户会话的"视频",将它们发送到后端服务器进行调试或重播视频.您可以将用户会话实时流式传输到另一个浏览器以获得用户帮助(或间谍以检查用户的实时UX行为).发送状态可能非常昂贵,但像Avro这样的格式可能有所帮助.或者,如果您的应用事件流是可序列化的,您可以简单地传输这些事件.我已经在框架中轻松实现了它,它可以在我的生产应用程序中运行(只是为了好玩,它不会向后端传输任何东西)

• 可以像在ELM中那样进行时间旅行调试

我为那些感兴趣的人制作了一个"JSON记录用户会话"的视频.