What is the best practice for interacting between React components and services?

Question

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

For example: There is a container with several representative (reactive) components:

• ChatBox - allows you to read / write messages
• AvatarBox with password change function - which allows you to change the user password
• News Feed - Lists news and applies a filter to them.

Thinking of them as a representation of resources, I want each of them to gain access to the Microservice API (receiving or updating data). It's right? It will provide pure responsibility for managing the models, but it does give performance problems using HTTP requests to load each component content.

This question also applies to: How to make effective communications for multiple (micro) services?

Answer 1

When you choose not to use Flux / Redux , here is what you do:

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

Do all the rest of the components (ChatBox, AvatarBox and NewsStream) . If you are not familiar with this concept, this means that they get everything they need through props , and they avoid saving the state. These components should not cause the microservices themselves. This is a responsibility of a higher order. To be interactive, these components must receive event handlers as props.

It is right? It will provide pure responsibility for managing the models, but it does give performance problems using HTTP requests to load each component content.

You can avoid performance issues with help by not allowing each component to access microservices directly . If your higher order component compiles all the necessary information and makes as few HTTP calls as possible, you should be fine with this approach.

Using Flux / Redux is usually recommended, but if you refuse, here is how to do it.

Answer 2

According to: https://facebook.imtqy.com/flux/docs/overview.html#content

Sometimes we may need to add additional kinds of controllers deeper in the hierarchy to support simple components. This can help us better encapsulate a section of the hierarchy related to a specific data area.

And this is what I think about the responsibility of a particular component domain (three of them have been described). So can it be reliable to create three types (or storages) of the controller that can access the dependent API to manage these resources?