jamesplease
Abort API
Heads up: Subsequent requests are "fake-aborted" by React Request. The request still continues on, and the result will even be stored in the cache, but the render prop won't be called when the response returns. This issue is specifically for adding support for true abort.
-
abortController -
abortOnUnmount
Pass true for abortOnUnmount to abort the request automatically when the component unmounts. It is only available when abortController is passed.
Update: The above doesn't really work for polling. I think the component will need to make its own AbortController and pass that down via render.
Also, abortOnUnmount could abort requests that other components are waiting for responses for as well, so it could be dangerous.
Todo:
- [ ] Come up with API
- [ ] Write Guide
Gonna close this as revisit. Blocked by https://github.com/github/fetch/pull/592
When this is added, I should consider an ability to distinguish between faux aborting and real aborting.
For instance, sometimes you really want the request to abort because you don't want to clog things up. Other times, you want the response to be ignored but still received, so that it gets cached and isn't "wasted."
Sure @andriijas , I'll reopen this, although I personally won't have time to code a solution for some time.
What I will do is type up all of my thoughts so far:
Ideally, the solution will account for both "modes" of operation of this component:
- calling
doFetch()(which puts the component in "manual mode") - prop changes (which is when the component is in "automatic mode")
The first case is relatively easy to solve for: because you are in control of when the HTTP request is made, you can just pass in a signal from an abortcontroller that you make at that time.
The second case isn't as obvious. In "automatic mode," you do not have control over when a request will be made, and it would be error-prone to try and control that. For that reason, the library would likely need to make the AbortController for you, and give you the abort method in the render function.
A problem with this is how to protect against people going with # 2 . Maybe we would warn if you pass the signal prop, and point to the docs that explain to you why that is a bad idea?
Two other problems are writing the guides on how to support the Abort API, and writing additional guides on the limitations of GitHub's fetch vs. native fetch.
If nobody sees any issues with the above, then the best way to get this landed would be to craft up a PR to try it out! (I won't have time to do that part unfortunately).
Thanks for reading!
I like the solution but unfortunately I dont have time to implement it right now either and I dont expect anyone else to hurry up about it either. But lets keep it open for future.
(Im just finishing up some stuff for a client where my contract is about to end. They had a paginated table in jquery/knockout where each row spawned a request, even if the paginated page was not rendered the req was spawned in background. Now at least when I migrated to react only rows that are rendred will make the request and responses will be cached thanks to react-request so at least there is some improvement.)