-
Notifications
You must be signed in to change notification settings - Fork 45
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Worker methods to return promises #3
Comments
+1 |
+1 (BTW, love this project. Just suffered through doing native web workers), with an ugly fallback for IE9. |
I like the idea of only using promises if the native API is available (having to include a promise lib as a dependency was why I avoided it thus far). +1 from me, I'll take a look. |
Yeah I hear you, and I appreciate that there are no external dependencies. It might be tricky to support folks that don't want promises, and people who want a jquery deferred. |
@evanworley jQuery.Deferred is not a valid Promises spec implementation :) Or at least it wasn't last time I checked (few months ago). |
I'm fine with detecting and using native/polyfilled promises, I can work with that. |
If you support promises please support both promises & callbacks. |
Ok, here's what I am proposing to solve the whole callbacks/promises issue: There will be three ways to "fulfil" (successfully return) something from within the worker. Directvar o = operative({
foo: function() {
return 123;
}
});
o.foo(function(err, result) {
result; // => 123
}); Async Basicvar o = operative({
foo: function() {
var finish = this.async():
// do async stuff ...
finish(456);
}
});
o.foo(function(err, result) {
result; // => 456
}); Async Promisevar o = operative({
foo: function() {
var resolver = this.deferred():
// do async stuff ...
resolver.fulfil(456);
}
});
o.foo().then(function(result) {
result; // => 456
}); There will be two different ways to reject from within a worker: Via Exceptionvar o = operative({
foo: function() {
// ...
throw new Error('something');
}
});
o.foo(function(err, result) {
err; // => 'something'
}); Via reject() (promise)var o = operative({
foo: function() {
var resolver = this.deferred();
// ...
resolver.reject('something');
}
});
o.foo().then(function() {
// fulfil callback (not called in this case)
}, function(err) {
err; // => 'something'
}); We will detect if you use Assuming this can all be implemented (I'm already in the process of doing this in a branch) is everyone happy with this API? I guess this'll have to be a |
After posting that I realised that we'll probably want event a direct return to fulfil a promise too? If so, that's gonna be tricky to reconcile with the existing regular-callback style. To be honest I prefer the explicit |
@padolsey The pull request looks good. Regarding your concern above for the direct return, I'd advocate for the same behavior whether or not any asynchronous code is executing inside the web worker. This way if the operative code changes in the future, say a synchronous block becomes asynchronous, not much will need to change. |
Merged |
Best would be probably to feature detect the native promises spec, and if present, return them from methods. People can than choose themselves to include polyfills.
A lot better than inlining it into the code, or adding a dependency...
The text was updated successfully, but these errors were encountered: