react 组件应该如何与服务通信，而不是使用flux/redux 架构？
例如： 有一个容器很少有代表性（反应）组件：
将它们视为资源表示，我希望它们中的每一个都能够自行访问微服务 API（获取或更新数据）。它是否正确？ 它将提供干净的责任管理模型，但使用 http 请求加载每个组件的内容会产生性能问题
本题也参考：How to execute efficient communication for multiple (micro)services?
【问题讨论】：
标签： rest reactjs redux flux microservices
当您选择不使用 Flux/Redux 时，您可以执行以下操作：
创建一个外部组件来包装所有其他组件。该组件也称为高阶组件或控制器视图。该组件应该使用 HTTP 库与您的微服务通信（我个人喜欢 Axios）。我建议您创建一个包装 Axios 的客户端 API 对象。您的高阶组件可以引用此客户端 API，因此它与 HTTP 库等无关。我还将在dev 模式下在window 对象上引用此客户端API，以便您可以在Chrome console 中执行window.clientApi.fetchSomething() 并简化调试。
使所有其他组件（ChatBox、AvatarBox 和 NewsStream）受控。如果你不熟悉这个概念，这意味着他们通过 props 获得了他们需要的一切，并且他们避免保持状态。这些组件不应自己调用微服务。这是高阶组件的责任。为了具有交互性，这些组件应该接收 事件处理程序 作为 props 的函数。
这是正确的吗？它将提供干净的责任管理模型，但使用 http 请求加载每个组件的内容会产生性能问题
您可以通过不允许每个组件直接联系微服务来避免性能问题。如果您的高阶组件编译了所有需要的信息并尽可能少地进行 HTTP 调用，那么您应该完全可以使用这种方法。
通常建议使用 Flux/Redux，但如果您选择退出，这就是如何去做。
【讨论】：
根据：https://facebook.github.io/flux/docs/overview.html#content
有时我们可能需要在更深处添加额外的控制器视图 层次结构以保持组件简单。这可能有助于我们更好地封装一个 与特定数据域相关的层次结构部分。
这就是我正在考虑的特定组件域的责任（描述了其中三个）。那么制作三个可以访问依赖API来管理资源数据的控制器视图（或存储）是否可靠？
【讨论】：