在React组件和服务之间进行通信的最佳实践是什么？

Question

代替使用flux / redux架构，组件应如何与服务进行通信？

例如： 有一个容器具有很少的代表性（反应）成分：

1. ChatBox - 支持读/写消息
2. 带密码更改器的AvatarBox - 可以更改用户的密码
3. 新闻流 - 列出新闻并对其应用过滤器

将它们视为资源表示，我希望它们中的每一个都能自己访问Microservice API（获取或更新数据）。它是否正确？ 它将提供清晰的责任管理模型，但它使用http请求加载每个组件的内容时会产生性能疑问

这个问题也适用于：How to execute efficient communication for multiple (micro)services?

Answer 1

当您选择不使用Flux / Redux 时，您就是这样做的：

创建一个应包装所有其他组件的外部组件。此组件也称为高阶组件或控制器视图。该组件应使用HTTP库与您的微服务进行通信（我个人喜欢Axios）。我建议您创建一个包装Axios的客户端API对象。您的高阶组件可以引用此客户端API，因此它与HTTP库和诸如此类的东西无关。我还会在window模式下在dev对象上引用此客户端API，以便您在window.clientApi.fetchSomething()中执行Chrome console并简化调试。

使所有其他组件（ChatBox，AvatarBox和NewsStream）受控。如果您不熟悉这个概念，则意味着他们通过道具获得所需的一切，并且他们避免保持状态。这些组件不应该自己调用微服务。这是高阶分量的责任。为了实现交互，这些组件应该接收事件处理程序作为props的功能。

  

这是对的吗？它将提供清晰的责任管理模型，但它使用http请求加载每个组件的内容时会产生性能疑问

您可以通过不允许每个组件直接联系微服务来避免性能问题。如果您的高阶组件编译所需的所有信息并尽可能少地进行HTTP调用，那么这种方法应该完全没问题。

一般建议使用Flux / Redux，但如果你选择退出，这就是如何去做。

Answer 2

根据：group join

  

有时我们可能需要在更深层次添加额外的控制器视图   层次结构以保持组件简单。这可能有助于我们更好地封装a   与特定数据域相关的层次结构部分。

这就是我在思考特定组件域的责任（其中三个被描述）。因此，制作可以访问依赖API来管理资源数据的三个控制器视图（或存储）是否可靠？