Found a flaw calling the same endpoint from multiple locations.

[Bram-Zijp]

I was trying to find a solution to a problem and noticed this module has the same flaw. Basically when you have two components that require the same API endpoint, it will fetch the data from that API endpoint twice.

I solved this by adding the fetch promise to the context provider by calling a function that sets it on the this scope in the provider from the hook. You could also use a useRef. Then in the hook I call a getData function that will return undefined/the fetch promise/the data from the context provider.

[RyanRoll]

You did the right thing that sharing the common data via React context to many components is a correct approach and that is able to avoid calling the same API by multiple times.

To be handy, I can support an additional option called useCache which can meet your requirement that only fetch the same API once. However, you need to be aware that when the cache data should renew and update it manually.

For example:

// in component A
const [data, { loading }, request] = useApi({
  url: '/api/foo/bar',
  { useCache: true }
})

// in component B
const [data, { loading }, request] = useApi({
  url: '/api/foo/bar',
  { useCache: true }
})

// to renew (update the cache data manually)
request()

Please let me know if it works for you and I will implement the enhancement.

[Bram-Zijp]

In my case, the fetch calls where happening at the same time, 2 or more components demanding the same data at page transition.

A useCache option could be usefull when you dont care about revalidating data after a while and it is required again.

I think it should be default behaviour to re-use previous fetches to the same enpoint if they still running.
My gut feeling says that a downside could be that component X tries to fetch data Y and is taking very long. 10 seconds progressed and compent Z just joined and also needs data Y. This will end up in the code re using the fetch from component X which got stuck some how while a new fetch could resolve. This could than be solved by clearing old fetches and reinitiating when # time has passed and it was requested again at a later time. I'm unsure if a previously made 'stuck' fetch will always resolve if a new request at a later time is resolving. I feel like there can be a function stuck on the backend of sorts that could possible resolve if like 5 seconds has passed since the last 'stuck' fetch call.

If the above was unclear or you want some help setting it up, id be happy to help.

[RyanRoll]

In my case, the fetch calls where happening at the same time, 2 or more components demanding the same data at page transition.

A useCache option could be usefull when you dont care about revalidating data after a while and it is required again.

I think it should be default behaviour to re-use previous fetches to the same enpoint if they still running.
My gut feeling says that a downside could be that component X tries to fetch data Y and is taking very long. 10 seconds progressed and compent Z just joined and also needs data Y. This will end up in the code re using the fetch from component X which got stuck some how while a new fetch could resolve. This could than be solved by clearing old fetches and reinitiating when # time has passed and it was requested again at a later time. I'm unsure if a previously made 'stuck' fetch will always resolve if a new request at a later time is resolving. I feel like there can be a function stuck on the backend of sorts that could possible resolve if like 5 seconds has passed since the last 'stuck' fetch call.

If the above was unclear or you want some help setting it up, id be happy to help.

Sorry for the late update these days, I've implemented the cache mechanism for particular API endpoints or all.
Please refer to alwaysUseCache.

Invoking request() triggers re-validation which means calling API forcibly regardless of cache data.
In addition, setting options.useCache to false will never use cache data.