首页 文章

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

提问于
浏览 次
3

而不是使用flux / redux架构，反应组件应该如何与服务进行通信？

For example: 有一个容器具有很少的代表性（反应）成分：

  • ChatBox - 允许读/写消息

  • 带密码更换器的AvatarBox - 可以更改用户密码

  • 新闻流 - 列出新闻并对其应用过滤器

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

这个问题也提到：How to execute efficient communication for multiple (micro)services?

rest reactjs redux flux microservices

2 回答

  • 4

    当你 opt for not using Flux/Redux 时，这就是你做的：

    创建一个 outer component ，它应该包装所有其他组件 . 此组件也称为 higher order component 或 controller view . 该组件应使用HTTP库与您的微服务进行通信（我个人喜欢Axios） . 我建议您创建一个包装Axios的客户端API对象 . 您的高阶组件可以引用此客户端API，因此它与HTTP库和诸如此类的东西无关 . 我还会在 dev 模式的 window 对象上放置此客户端API的引用，以便您可以在 Chrome console 中执行 window.clientApi.fetchSomething() 并使调试更容易 .

    制作所有其他组件（ChatBox，AvatarBox和NewsStream） controlled . 如果你不熟悉这个概念，那就意味着他们通过 props 收到他们需要的一切，他们避免保持状态 . 这些组件不应该自己调用微服务 . 这是高阶分量的责任 . 为了实现交互，这些组件应该像道具一样接收 event handlers .

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

    您可以通过 not allowing each component to directly contact the microservices 避免性能问题 . 如果您的高阶组件编译所需的所有信息并尽可能少地调用HTTP，那么这种方法应该完全没问题 .

    通常建议使用Flux / Redux，但如果你选择退出，这就是如何去做 .

    回复于
  • 0

    根据：https://facebook.github.io/flux/docs/overview.html#content

    有时，我们可能需要在层次结构中更深层地添加其他控制器视图，以保持组件简单 . 这可以帮助我们更好地封装与特定数据域相关的层次结构的一部分 .

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

    回复于

相关问题