Support for async predicate

[louiealmeda]

There are use cases that would need to repeatedly call an async operation until a certain condition is met. For instance, an API call.

something like:

await waitUntil( async ()=>{
   
   const response = await api.get(); //any async operations
   return response.status == 200;

})

Currently, having an async predicate skips the waitUntil predicate entirely

[dongyu063]

@louiealmeda Just add await before predicate(); in line 36.
result = await predicate(); => result =predicate();

[zorji]

@louiealmeda PR created in #4

I didn't use await in case the code is running in Node env that doesn't support async.

[louiealmeda]

that's awesome @zorji I hope it gets pulled in.

[yunj]

Hi @devlato just wondering if you are going to merge this pull request? We have the same need. Thank you very much.

[OnTheWehn333]

Hello, I also have a need for this. Looking forward to getting the new changes. Do you know when it'll be available? Thanks for your hard work and making such a useful library.

[devlato]

@louiealmeda why don't you just do this 🙂

while (true) {
  const response = await api.get(); // Any async operation
  if (response.status === 200) {
    break;
  }
}

In case of async predicate, there's a natural way of pausing and proceeding the execution flow, so the above snippet would solve your issue 🤷‍♂️

[devlato]

Otherwise, as per this library design, it should do the following:

1. Run the predicate.
2. Wait for it to complete and the returned Promise to resolve.
3. If the Promise returned from the predicate doesn't resolve within timeout ms, throw a timeout error.
4. If it gets resolved with a falsy value and there's still time for another attempt, retry the predicate and go to step 2.
5. If if gets resolved with a truthy value, return the last result.

If this behaviour is what you would expect from the library, I'm keen to make change and publish an updated version.

[louiealmeda]

Hi @devlato, thanks for looking into this. Indeed, we can do the solution that you've posted, but it can quickly become messy when we need to do a lot of waits, especially when we want to set timeouts for them. I believe it is that problem that this library is actually solving...

Yes the flow seems correct to me, and looks aligned with @zorji's PR

Cheers.

[zorji]

Hi @devlato @louiealmeda

It seems it's possible to carry on the discussion in this thread, I'll close my PR

A better implementation should consider wait AFTER the previous Promise resolved but since I don't need the change any more I'll close mine.

[devlato]

Hey folks, have just merged v2.0.0 (#5) and will publish it to npm shortly. The updated documentation is available in the project README. Additionally, auto-generated documentation is available on GitHub Pages.

[devlato]

I'm closing this issue, please re-open or create a new one if this is still an issue after upgrading to 2.0.0.