使用React`context`来访问无Flux应用程序中的模型mutators是否合理？

Question

我正在开始一个新的React应用程序，看到生态系统中的所有新闻，我想慢下来，实际上考虑我的选择，从React / Webpack / Babel开始，并引入更多。

这些选择中的第一个是否使用Flux（更准确地说，Redux，它看起来很棒并且似乎赢得了助威战争）。我就是这样的地方：

1. 我理解Redux的好处，summarized on SO by Dan Abramov。它们看起来很棒，但我宁愿一步一步地介绍。
2. 在简单的React中，父级→子级通信使用道具完成，子级→父级通信使用回调。请参阅Doc / Communicate Between Components或SO / Child to parent communication in React (JSX) without flux或this codeacademy Redux tutorial，其中首先说明“如果您使用简单的React并且根组件中的所有数据都可以，则不需要Redux” 。
   • 看起来很适合我的目的......
   • ... 然而，令人遗憾的是，这些回调必须在组件链中传递，这很快就会变成tedious as the levels of nesting grow。

为了解决这个问题而不引入新的依赖关系，我发现有两篇文章（1: Andrew Farmer，2: Hao Chuan）鼓励使用最近推出的context feature of React。

→使用context可以让我将模型变异回调暴露给我的子组件。对我而言，这听起来并不是一个可怕的误用：我不会传递模型数据，只是引用用于绑定事件处理程序的函数。

• 听起来是否合理？
• 任何其他简单的React建议方便孩子→家长沟通？

感谢。

Answer 1

在观看Dan Abramov的Getting Started with Redux系列节目之后回答我自己的问题，我热烈推荐。

是的，看起来很明智：Redux遇到了同样的问题并用Context 解决了这个问题（至少在最初阶段，实施可能已经改变）。它在react-redux组件和<Provider>函数下的connect()绑定中实现和打包（以及其他内容）。

1. 最初，在步骤24 - Passing the Store Down Explicitly via Props 开始时，我们有一个Todo应用程序，其中Redux商店可用作顶级变量。这很糟糕（1.可测试性/可模拟性，2。服务器渲染需要＆＃34;每个请求都有不同的商店实例，因为不同的请求有不同的数据＆＃34; ），所以商店从降级顶级变量到根组件prop。

2. 在我的情况下，必须将商店作为prop传递给每个组件是令人讨厌的，因此在25 - Passing the Store Down Implicitly via Context中，Dan演示使用Context将Redux存储传递给任意嵌套的组件。

3. 接下来是26 - Passing the Store Down with <Provider> from react-redux，解释了如何将其封装在react-redux绑定中。

4. 27 - Generating Containers with connect() from React Redux进一步封装了表示组件中容器组件的生成。

Answer 2

就个人而言，如果你想一想Angular中依赖注入的方式，我觉得这个问题很容易回答。在Angular中你有你的DOM，然后你拥有所有那些独立于DOM结构的服务，提供者，工厂，常量和诸如此类的东西，只需在创建模块或控制器时提及他们的名字就可以导入。

我将this.context的使用比作DI。 w.r.t与Angular的不同之处在于，不是使用函数参数名称声明依赖关系，而是使用childContextTypes而不是将依赖关系作为函数参数，而是通过this.context获取它们。

从这个意义上讲，询问是否通过this.context传递模型mutators的问题是明智的，归结为在Angular中注册依赖注入模型是否有意义。我从来没有见过后者的问题，因此我推断前者也很好。

但是，我并不是说它适合图书馆的精神。依赖注入，特别是管理注入组件之间的依赖关系并不明确，因此有人可能认为它不是React方式。我把这个哲学讨论留给别人。