Closed ghost closed 6 years ago
What would be the role of the queue
in that case? What kind of work is going to be dispatched on it?
In that queue
will be executed all Then, Always, Catch, Then ...
closures
So, if I understand that correctly, you suggest passing a queue into the promise constructor, so that any consumer of that promise would automatically get their subscriber methods (akin then
, catch
, etc.) be dispatched on that queue by default?
I guess the tricky part is that the consumers of your promise (e.g., if it were provided by some library API) wouldn't be aware that then
they chain on w/o specifying any queue explicitly will be dispatched on your private queue the promise was created with, instead of the main.
Imagine:
func foo() -> Promise<Void> {
let promise = Promise<Void>.pending(queue: queue)
promise.fulfill(())
return promise
}
func bar() {
foo().then {
// Present UIViewController.
}
}
bar()
has no idea the promise it gets from foo()
is going to be dispatched on a private queue, so it can assume it's the main queue, as always, and try to do some UI interactions.
The idea of the methods like then
, catch
, etc. is to observe promise state changes. And such observations can be dispatched on any queue specified. In other words, it's up to subscribers which queue they want to use:
foo().then(on: queue) {
// Do something on queue.
}
foo().then { // Equivalent to .then(on: .main)
// Do something on the main queue.
}
If, for some reason (like you're using Promises on a server side and need to park the main thread in a custom runloop mechanism), you want to use some other queue by default rather than the main for all promise APIs, do the following:
DispatchQueue.promises = queue
foo().then {
// Do something on queue.
}
It's possible to do something like this ?:
or
after that resolve if manually