Repository navigation
Interoperability Implementation #64
Description
Do you plan to implement https://github.com/async-interop/awaitable? Would you mind to provide feedback?
Do you plan to implement https://github.com/async-interop/awaitable? Would you mind to provide feedback?
Activity
jsor commentedon Sep 23, 2016
I'm planning to support at least consuming awaitables through
resolve.What kind of feedback would you like to have and where? Any specific issues or just general feedback?
kelunik commentedon Sep 23, 2016
Mostly general feedback whether it's fine in the current state. Most actively involved people come from Icicle and Amp, would be good to have also feedback from React.
The signature should be compatible, I hope the order requirements and other requirements are compatible as well.
jsor commentedon Sep 26, 2016
The only problem i see is the requirement of an event loop implementation. React/Promise doesn't require an event loop. I fear this will block us from implementing the interface directly.
Will there be a test suite like the one for the event loop?
kelunik commentedon Sep 26, 2016
I don't know whether we can provide a test suite, as the interface only standardizes how promises / awaitables can be consumed, not how they're resolved.
That might indeed be an issue. If you can't implement the interface directly, I guess we have to live with adapter functions. React doesn't have the issue with the callbacks throwing, as that just fails the returned promise. /cc @bwoebi
bwoebi commentedon Sep 26, 2016
Regarding the event loop, we can just make the behavior undefined in case it's lacking. Thus, React can handle it it's own way if there's no event-loop. If people use
when()with no event loop driver factory registered, it's their fault.After all it just applies to the quite rare case that a callback is throwing, which usually should not happen anyway. It's just for uncaught top-level error condition handling.
@jsor À propos tests, how can we test an interface with only a mere callback registering method, as the interface doesn't specify a way to trigger the callbacks?
jsor commentedon Sep 27, 2016
The introduction of a task queue in 3.0 (which defaults to a synchronous implementation but can be replaced with an event loop based implementation) will probably solve this.
Regarding the tests: I thought about something like the Promises/A+ Compliance Test Suite where you can provide an adapter and then validate if your implementation complies with the spec.
bwoebi commentedon Sep 27, 2016
Okay, I'll give a shot at the tests this evening.
Add note about behavior being undefined if there's no loop upon excep…
bwoebi commentedon Oct 24, 2016
@jsor Turns out "This evening" was a bit too ambitious :-P
Anyway, here it is: https://github.com/async-interop/awaitable-test - I hope this suits your needs? (The loop is optional and just needed for one test, which is skipped if driver set to null)
Add note about behavior being undefined if there's no loop upon excep…
jsor commentedon Oct 24, 2016
@bwoebi Great, thanks! I will look into it and see if we can consider implementing Awaitable directly for 3.0.
jsor commentedon Nov 30, 2016
I've done an implementation for 2.x if anyone wants to review: 2.x...2.x-async-interop
@bwoebi I've copied your tests over because your repository is still using
Awaitableinstead ofPromise.kelunik commentedon May 27, 2017
Closing as no longer relevant. Amp v2 will have built-in support for React's promises, maybe React wants to do something similar, but that should be discussed in a separate issue.