Cannot timeout $resource action more than once

[Hartimer]

$resource uses $http underneath. $http (and $resource by inheritance) supports cancelling requests by passing a number or promise to the timeout parameter of the config object.

The issue is that the $http.config must be defined along side the resource itself. This means that the promise passed to the resource can only be resolved (effectively cancelling the request) once.
This makes the timeout useless for a resource, which conceptually speaking might be long-lasting and have actions called on it multiple times.

My suggestions

Option 1:
Support passing $http configurations with each resource action call, e.g.:

myResource.$myAction(
   {/**/}, 
   {timeout: ...}, 
   <success_handler>, 
   <error_handler>
)

Disruptive since it effectively changes the signature of the method, unless the new attribute is added as the last arg.

Option 2:
Make the timeout property support number|promise|function, that way we could specify a function that would provide a promise (or number) each time the request was made

It would be my first PR but I would like to implement one or both of the options if you find them valid.

[caitp]

If the timeout property is a number (greater than 0), then essentially setTimeout is used instead, and this will work for multiple requests.

[Hartimer]

@caitp yes, using a number works every time, but a promise doesn't. Example use case:

I have a resource "Car" with an action "$weight". Somewhere in my app I want to check the weight given some condition, like changing a select.

When you change the select you want to cancel the previous request, since it will be outdated and could potentially return an error "Over weight" which could not be true anymore. A promise (afaik) is the only way to achieve this behaviour, if it could be used more than once

[caitp]

Right, well there's no way to add more httpConfig options without drastically changing the API in not good ways, but maybe we could let you pass a function to the timeout parameter which returns a promise (and throws if the returned value isn't a promise), this doesn't seem unreasonable.

[Hartimer]

Potentially the function could return either a number or a promise, but indeed it seems like the least disruptive approach. Thanks for the feedback btw.

I'll wait for some more feedback before tackling it.

[kayhadrin]

+1

[gkalpak]

This has been resolved with 98528be.