ava
Fetching too quickly causes race conditions
Describe the bug
Invoking the get function too quickly in a short amount of time causes race conditions.
⚠️ Make a Codesandbox ⚠️ https://codesandbox.io/s/use-http-race-conditions-ecnqt?file=/src/App.js
To Reproduce Steps to reproduce the behavior:
- Go to your developer console (cmd + option + i on chrome)
- Navigate to your network tab
- Simulate a slower connection speed by clicking the throttle tab and selecting fast 3g
- Click the button several times very quickly
- Observe the network requests. The UI will not reflect the latest request data
Expected behavior I know this is a heavily contrived example, but it essentially mirrors the behavior I'm experiencing in a production app. A date picker has arrow buttons that allow the user to quickly change date query params that fire off a new useFetch request with each click. If the user clicks too quickly, then 90% of the time, I'll end up with UI that shows previous request data. After some amount of time (sometimes 30 seconds to a minute) the UI eventually updates to reflect the latest request data.
Note: I tried using the abort function exposed from useFetch to abort all previous requests, but this seems to abort only every other previous request or so.
This happened to me a couple of times.
The temporary workaround I had is to create a map where the keys are URLs and the values are response.data. And then you can get the right data from the map by passing the URL (basically caching outside of useFetch).
But it would be great if this is fixed in the library.
Is this a matter of calling get consectuively? Could we have deferred it?
I'm trying with abort() before the get() but it doesn't abort all the requests, only the first one when these are racing. Maybe the abort() should abort all the requests?
Yes abort seems to be completely broken. If you try to use it for a searchbar, it lets most of the requests complete even when I'm aborting each time individually.
