You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
This repository was archived by the owner on Apr 12, 2024. It is now read-only.
After accepting PR #2529 ("add support for timeout promises") the timeout parameter for $http can be a promise, and resolving it will abort the request.
$resource passes actions to $http so one can also pass timeout promise.
However if I initialize a $resource object to use it for multiple "class" actions requests, I can specify timeout only once — at the moment of initialization. All the requests made by this object will share the same timeout promise, so effectively only one of them can be aborted.
So far I am planning to write a patch to add $abort() method to the object returned by "class" actions requests of $resource. However even at this stage the resulting mix of APIs does not seem nice. (Neither does cancelling via timeout promise, by the way.)
I imagine that cancelling API should be the same for $http requests and $resource requests. Passing an object as a parameter to be able to abort the request does not seem right. Given how $resource is used, $abort method belongs to the object returned by $resource "class" actions calls. However instance call returns promise, and we cannot reject it. Should the aborting API be different for instance and non-instance calls?
Your ideas on the best approach to that problem are welcome!