CODEWITHSUNDEEP
javascriptreactjs
skyscript
skyscript

Reputation: 175

In React, is it good practice to make endpoint calls at every component level where needed?

I have a React container that makes an endpoint call to retrieve JSON data and then pass the response to a child component as a proptype. Now, based on the response, the app needs to make more endpoint calls to get other data. Is it good practice to make a second call from the child component, then from that response pass data down to a deeper child component, and so forth down the component tree? Or is it better practice to make all the calls in the top level container and pass the data down the component tree?

e.g.

--------------------     ----------------------     -------------------
|                  |     |                    |     |                 |
| Container        |-----| Child A            |-----| Child B         |
|                  |     |                    |     |                 |
--------------------     ----------------------     -------------------

Make endpoint call.       Gets data from              Gets data from
Pass data obj to          Container via props.        Child A via props.
Child A.                  Render some data.           Render some data.
                          Make another endpoint   
                          call and pass data obj
                          to Child B.

Or..

--------------------     ----------------------     -------------------
|                  |     |                    |     |                 |
| Container        |-----| Child A            |-----| Child B         |
|                  |     |                    |     |                 |
--------------------     ----------------------     -------------------

Make multiple endpoint    Gets data obj from         Gets data obj from
calls.                    Container via props.       Child A via props.
Pass all data in a        Render some data.          Render some data.
data obj to Child A.      Pass data obj to        
                          Child B.

Upvotes: 2

Views: 1866

Answers (2)

Dave Newton
Dave Newton

Reputation: 160211

The second option is (mostly) better for a variety of reasons.

  • It allows easier testing at the component level.
  • It allows easier changeout of data fetching mechanisms.
  • In this case it localizes all the "external" work.

The only drawback is that if you reuse your component across multiple applications you either need to re-implement data fetching, or wrap it up in an exportable module along with the component.

For example, we have a number of components that load up on our dashboard. We needed to make those available to other consumers, e.g., embedding on a third-party page. For that reason we kept the data fetching local to the component, although the components still follow the container/component model.

This allows a consumer to grab the entire component and drop it in to their own app. They could, however, choose to import only the component and implement their own fetching mechanism.

Upvotes: 1

Pedro Castilho
Pedro Castilho

Reputation: 10532

Based on the separation of presentational and container components, the more "pure" your presentational components are, the better. This means that the fewer components deal with the outside world, the better your code will be in general. This is also supported by software architecture design and functional programming practice: The part of your software which interacts with "the real world", by doing stuff such as taking user input or getting data from APIs, should be as small as possible. Most of the work in your software should be done within the confines of the software itself.

You should design your architecture in such a way that your container does most of the work in interacting with the real world, and child components only display that data. There are many React libraries which deal with the problem of orchestrating complex sequences of API calls which you can use so that your container does not become a garbled mess of code. redux-saga seems like a good fit for your problem.

The second option you proposed is very much the better one.

Upvotes: 3

Related Questions