使用Om,似乎将app状态的相关部分传递给子组件实际上与不传递任何app状态但使用ref-cursors是一回事. ref-cursors在链条上传递app状态的用例是什么？

我已经阅读了Om github存储库中的所有三个教程和概念性概述,但我真的找不到这个问题的答案.似乎可以使用其中一个或另一个并完成相同的事情(一个定义一个组件(defn blah [_ owner] …)并使用ref游标或定义一个组件(defn blah [relevent-state]老板] …)

有人可以澄清何时我想在组件中使用引用游标而不是简单地将部分应用程序状态传递到该组件中？

最佳答案 这个问题很老了,但我会试一试.

我相信ref-cursors的主要用例是促进模块化以及将全局应用程序状态与组件分离.它将组件的范围限制为它们所依赖的数据,而不是其他任何东西.

通常,您可以通过props将应用程序状态和任何更改回调传递给组件树,如您所说.结果是组件层次结构与应用程序状态的“形状”紧密耦合.组件层次结构必须与状态1：1匹配,否则许多组件将接收大量数据和回调,只有少数子组件依赖,他们自己可能永远不会实际使用 – 你可能会发现自己传递的部分组件链中的全局状态,以便进一步向下的组件可以访问它.这些组件被用作传递状态的通道,这不是理想的,因为它将它们暴露给他们没有业务知道的应用程序状态.您冒着耦合和失去模块化的风险.

使用游标,每个组件在安装时都会明确指定组件依赖性.游标是进入应用程序状态的黑盒子 – 组件本身永远不必知道它所在的应用程序内部.您可以充分灵活地在应用程序状态的任何位置声明组件的依赖关系,而无需担心传递的所有瞬态数据.您可以获得单向数据流,而无需在任意深层次结构中传递更新回调.最终结果是出色的组件划分和模块化.作为奖励,您现在可以在应用程序状态中有一个点,您可以观察到更改！