Skip to content
This repository was archived by the owner on Aug 3, 2023. It is now read-only.
This repository was archived by the owner on Aug 3, 2023. It is now read-only.

Serial requests? #59

@jamesplease

Description

@jamesplease

<ReactComposer /> works well for parallel requests, but what is the solution for serial requests?

Consider:

  1. Get Data A from Endpoint A
  2. Use Data A to make request to Endpoint B, receiving Data B
  3. Use Data A + Data B to make a request to endpoint C

What do this look like in the component-based world?

The "problem" is that step 2 requires an "event": knowing the moment that the request to Endpoint A has completed. Using React lifecycle tools (which is what we have available given the render-based approach to HTTP requests in this lib), capturing events requires comparing past data to future data, such as:

if (prevProps.fetching && !this.props.fetching) {
  console.log('hey cool, the request just ended');
}

With render props, there are no prevProps passed. This makes me think that a little library solution could be useful here, but I'm not certain of what the API would look like yet.

p.s. afterFetch doesn't work so well here since it is not a render prop, so it can't invoke another <Fetch />. However, it could store some data in-scope to be used within render, although that would likely be awkward for users of this lib.

p.p.s. I don't believe that React Apollo has anything for this, since it is GraphQL, and the queries tend to do everything in a single request.


Update:

One idea is:

<SerialFetch
  requests=[
    () => <Fetch {...props} />,
    (firstResult) => <Fetch {...props} />,
    (firstResult, secondResult) => <Fetch {...props} />,
  ]
  render={({ loading, error, data }) => {
    // do stuff
  }} />

The behavior would be as follows:

  1. loading is true until the last request ends
  2. if any of the requests error, then that error will be passed as error
  3. data will be an array of the results of each of the requests

🤔

If the name ends up being SerialFetch, then I should probably rename FetchComposer to be ParallelFetch or something. Or, possibly, one component, MultiFetch with a flow prop or something. The issue with this is that the requests API would be different for the different flows which isn't ideal.

Metadata

Metadata

Assignees

No one assigned

    Labels

    questionFurther information is requested

    Projects

    No projects

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions