What is best practice to communicate between React

问题:

Instead of using flux/redux architecture, how react components should communicate with services?

For example: There is a container having few representational (react) components:

1. ChatBox - enables to read/write messages
2. AvatarBox with password changer - which enables to change user's password
3. News stream - lists news and apply filter to them

Thinking of them as resources representation, I want each of them to access Microservice API by itself (getting or updating data). Is this correct? It will provide clean responsibility managing models, but it gives performance doubts using http requests to load each component's content

This question also reffers to: How to execute efficient communication for multiple (micro)services?

回答1:

When you opt for not using Flux/Redux, here is what you do:

Create an outer component that should wrap all the other components. This component is also known as a higher order component or a controller view. This component should use an HTTP library to communicate with your microservices (I personally like Axios). I would recommend that you create a client API object that wraps Axios. Your higher order component can reference this client API so it is agnostic of the HTTP library and whatnots. I would also put a reference of this client API on the window object in dev mode so you can do window.clientApi.fetchSomething() in the Chrome console and make debugging easier.

Make all the other components (ChatBox, AvatarBox and NewsStream) controlled. If you are not familiar with this concept, it means they receive everything they need through props and they avoid keeping state. These components should not call the microservices themselves. This is responsability of the higher order component. In order to be interactive, these components should receive event handlers as functions as props.

Is this correct? It will provide clean responsibility managing models, but it gives performance doubts using http requests to load each component's content

You can avoid performance issues by not allowing each component to directly contact the microservices. If your higher order component compiles all the information needed and make as little as possible HTTP calls, you should be perfectly fine with this approach.

It's generally recommended to use Flux/Redux, but if you opt out, this is how to go about it.

回答2:

According to: https://facebook.github.io/flux/docs/overview.html#content

Occasionally we may need to add additional controller-views deeper in the hierarchy to keep components simple. This might help us to better encapsulate a section of the hierarchy related to a specific data domain.

And this is what I am thinking about responsibility of particulary component's domain (three of them was described). So could it be reliable to make three controller views (or stores) that can access dependent API to manage resource's data?