Add waitFor function to enable waiting for async functions

[bendemboski]

Extracted from #81

A couple of notes:

• I have not address Wait for coroutine #81 (comment) because I'm still a typescript noob and a jsdoc noob (so noob squared here)
• I had to do some interesting acrobatics to keep the waitForPromise tests reasonably DRY -- I'm definitely open to other ideas if anyone has any

[scalvert]

@bendemboski - @rwjblue and I revived this one. Thanks so much for taking it as far as you did!

We've made a few changes, namely kept the waitForPromise API as it was, and added the waitFor API to provide the async function/decorator support. I think this will be a really nice addition to the addon.

Let me know if you have any thoughts/suggestions.

[bendemboski]

LGTM. I think the two additional items in the original PR that are probably mostly ready (I'll have to revive them from my repo's branches) are:

1. babel transform to strip waitForPromise() and waitFor() from the build
2. waitForCoroutine()

Any changes on those fronts, or continue with the original plans?

[scalvert]

I think the idea is that we layer on generator support into waitFor. Let me sync with @rwjblue after this is merged and we'll articulate the changes in an issue. I'll make sure to @ you on it.

As for the stripping, is that so we can reduce the size of the bundle?

[bendemboski]

I think the idea is that we layer on generator support into waitFor. Let me sync with @rwjblue after this is merged and we'll articulate the changes in an issue. I'll make sure to @ you on it.

Oh, gotcha, that makes sense from an API standpoint. And I think I can maybe picture how to implement it? We'd need to make the wrapper function look at the return value, and if it looks like an iterator, then wrap it in our own iterator instrumented with test waiter calls, instead of wrapping it in waitForPromise(), and return that...I think that would work?

As for the stripping, is that so we can reduce the size of the bundle?

Yeah, this was originally something requested by @rwjblue and my cut at it was here.

[scalvert]

@bendemboski yes that's exactly what we were thinking WRT the generator - essentially inspecting the shape of the return value to determine if it's an iterator, and wrapping it as you said.

As for stripping, I think we can wait on that. I think the idea we had was to still ship these things in the prod bundle, as we ultimately want to be able to run tests against a prod bundle, but still have it wait for async. If we strip, we can't do that.

This is predicated on us moving away from using the DEBUG flag, but something intermediate to evaluate whether we're in test mode or not.

[rwjblue]

As for stripping, I think we can wait on that. I think the idea we had was to still ship these things in the prod bundle, as we ultimately want to be able to run tests against a prod bundle, but still have it wait for async.

Ya, this just means we need another flag (DEBUG is not good enough here, because we need ember test --environment=production to be able to work.

[bendemboski]

Gotcha. Okay, once this is finalized/merged I'll make some time to port the waitForCoroutine() implementation into waitFor().

[rwjblue]

Note: @bendemboski I think we would add the check for iterator here just like the isThenable thing (iterator being something with a typeof result.next === 'function' I believe)

[scalvert]

Ya maybe add an isIterable?