使用Om，似乎将app状态的相关部分传递给子组件实际上与不传递任何app状态但使用ref-cursors是一回事。 ref-cursors在链条上传递app状态的用例是什么？
我已经阅读了Om github存储库中的所有三个教程和概念性概述，但我无法真正找到这个问题的答案。似乎可以使用其中一个或另一个来完成相同的事情（一个用(defn blah [_ owner] ...)定义一个组件并使用ref游标或用(defn blah [relevent-state owner] ...)定义一个组件
有人可以澄清何时我想在组件中使用引用游标，而不是简单地将部分应用程序状态传递到该组件中？
答案 0 :(得分：1)
我使用它是因为当你更新它时，所有观察者都会被调用。
答案 1 :(得分：1)
这个问题很老了，但我会试一试。
我认为ref-cursors的主要用例是促进模块化以及将全局应用程序状态与组件分离。它将组件的范围限制为它们所依赖的数据，而不是其他任何东西。
正如您所说，通常情况下，您可以通过道具将应用程序状态和任何更改回调传递给组件树。结果是组件层次结构与＆＃34;形状紧密耦合。应用程序状态。组件层次结构必须与状态1：1匹配，否则许多组件将接收大量数据和回调，只有少数子组件依赖，他们自己可能永远不会实际使用 - 你可能会发现自己传递的部分组件链中的全局状态，以便进一步向下的组件可以访问它。这些组件被用作传递状态的通道，这不是理想的，因为它将它们暴露给他们没有业务知道的应用程序状态。你冒着耦合和失去模块性的风险。
使用游标，每个组件在安装时都会明确指定组件依赖性。游标是进入应用程序状态的黑盒子 - 组件本身永远不必知道它所在的应用程序内部。您可以充分灵活地在应用程序状态的任何位置声明组件的依赖关系，而无需担心传递的所有瞬态数据。您可以获得单向数据流，而无需在任意深层次结构中传递更新回调。最终结果是出色的组件划分和模块化。作为奖励，您现在可以在应用程序状态中找到一个点，您可以观察到更改！