soffes / RateLimit

Simple utility for only executing code every so often.

Geek Repo:Geek Repo

Github PK Tool:Github PK Tool

Defer execution until end of limit

AnthonyMDev opened this issue · comments

I think this library is a really great idea, but I have one question about how this would work.

I would like to use RateLimit within updateSearchResultsForSearchController(), as is shown in Little Bytes Of Cocoa 81. http://i.imgur.com/srdLoLr.png

My problem is, though I don't want to call the search request too often, if the user STOPS typing then the request should be made no matter what. I don't want to have the user type in My Search Term but the last network request was with the query My Sea. Their results would be pretty off in that case.

Does RateLimit already implement anything to handle this scenario? I'm thinking of maybe having an option where, if at any point DURING the limited time execute is called again, then the call will be deferred until the end of the limit time. It would only execute once at the end of the limit time, no matter how many times execute was called during that time.

Is this already implemented? If not, is it a viable addition?

This does not appear to be implemented. The tests as written expect that the block isn't called during the limit period.

But yeah this seems like a nice feature to me, especially as an optional parameter that defaults to false, something like:

RateLimit.execute(name: "UpdateFoo", limit: 0.3, defer: true) {
    Foo.Update()
}

This would mean that calling execute N (where N > 1) times within the limit period would result in exactly two executions of the block: the initial call to execute that happens at t=0 and the deferred call that happens at t=limit.

Good idea!

@soffes Do you plan on implementing this then? If not, I can try to make a PR if I can find some extra time, but no promises at the moment. ;)

I too would like this behavior, and was hoping it was already in place. It would be a poor UX if the user is trying to type "disneyland", they typed "disneyl" and they're only getting suggestions for "dis" just because of their timing in typing. It seems the deferred proposal will work great and solve this problem. Hoping this can be implemented really soon!

That would be fantastic! :D

PR #16 closes this!
It also fixes a critical bug #15.
Awaiting review by @soffes

This has been implemented in #25.