Promise/A+ compliant, Bluebird inspired, implementation in Swift 5
- Promise/A+ Compliant
- Swift 5
- Promise Cancellation
- Performance
- Lightweight
- Unit Tests
- 100% Documented
https://andrewbarba.github.io/Bluebird.swift/
- iOS 9.0+ / macOS 10.11+ / tvOS 9.0+ / watchOS 2.0+
- Xcode 10.2
- Swift 5
// swift-tools-version:5.0
import PackageDescription
let package = Package(
name: "My App",
dependencies: [
.package(url: "https://github.com/AndrewBarba/Bluebird.swift.git", from: "5.1.0")
]
)CocoaPods 1.5.0+ is required to build Bluebird
pod 'Bluebird', '~> 5.0'github "AndrewBarba/Bluebird.swift" ~> 5.0
- Barstool Sports
- Tablelist − A Better Night Out
- NightPro − Venue & Event Management
- EverybodyFights Training Camp
Using Bluebird in production? Let me know with a Pull Request or an Issue.
Promises are generic and allow you to specify a type that they will eventually resolve to. The preferred way to create a Promise is to pass in a closure that accepts two functions, one to be called to resolve the Promise and one to be called to reject the Promise:
let promise = Promise<Int> { resolve, reject in
// - resolve(someInt)
// - reject(someError)
}The resolve and reject functions can be called asynchronously or synchronously. This is a great way to wrap existing Cocoa API to resolve Promises in your own code. For example, look at an expensive function that manipulates an image:
func performExpensiveOperation(onImage image: UIImage, completion: @escaping (UIImage?, Error?) -> Void) {
DispatchQueue(label: "image.operation").async {
do {
let image = try ...
completion(image, nil)
} catch {
completion(nil, error)
}
}
}func performExpensiveOperation(onImage image: UIImage) -> Promise<UIImage> {
return Promise<UIImage> { resolve, reject in
DispatchQueue(label: "image.operation").async {
do {
let image = try ...
resolve(image)
} catch {
reject(error)
}
}
}
}Okay, so the inner body of the function looks almost identical... But look at how much better the function signature looks!
No more completion handler, no more optional image, no more optional error. Optionals in the original function are a dead giveaway that you'll be guarding and unwrapping in the near future. With the Promise implementation that logic is hidden by good design. Using this new function is now a joy:
let original: UIImage = ...
performExpensiveOperation(onImage: original)
.then { newImage in
// do something with the new image
}
.catch { error in
// something went wrong, handle the error
}You can easily perform a series of operations with the then method:
authService.login(email: email, password: password)
.then { auth in userService.read(with: auth) }
.then { user in favoriteService.list(for: user) }
.then { favorites in ... }Notice each time you return a Promise (or a value) from a then handler, the next then handler receives the resolution of that handler, waiting for the previous to fully resolve. This is extremely powerful for asynchronous control flow.
Any method in Bluebird that accepts a handler also accepts a DispatchQueue so you can control what queue you want the handler to run on:
userService.read(id: "123")
.then(on: backgroundQueue) { user -> UIImage in
let image = UIImage(user: user)
... perform complex image operation ...
return image
}
.then(on: .main) { image in
self.imageView.image = image
}By default all handlers are run on the .main queue.
Use catch to handle / recover from errors that happen in a Promise chain:
authService.login(email: email, password: password)
.then { auth in userService.read(with: auth) }
.then { user in favoriteService.list(for: user) }
.then { favorites in ... }
.catch { error in
self.present(error: error)
}Above, if any then handler throws an error, or if one of the Promises returned from a handler rejects, then the final catch handler will be called.
You can also perform complex recovery when running multiple asynchronous operations:
Bluebird.try { performFirstOp().catch(handleOpError) }
.then { performSecondOp().catch(handleOpError) }
.then { performThirdOp().catch(handleOpError) }
.then { performFourthOp().catch(handleOpError) }
.then {
// all completed
}Useful for performing an operation in the middle of a promise chain without changing the type of the Promise:
authService.login(email: email, password: password)
.tap { auth in print(auth) }
.then { auth in userService.read(with: auth) }
.tap { user in print(user) }
.then { user in favoriteService.list(for: user) }
.then { favorites in ... }You can also return a Promise from the tap handler and the chain will wait for that promise to resolve:
authService.login(email: email, password: password)
.then { auth in userService.read(with: auth) }
.tap { user in userService.updateLastActive(for: user) }
.then { user in favoriteService.list(for: user) }
.then { favorites in ... }With finally you can register a handler to run at the end of a Promise chain, regardless of it's result:
spinner.startAnimating()
authService.login(email: email, password: "bad password")
.then { auth in userService.read(with: auth) } // will not run
.then { user in favoriteService.list(for: user) } // will not run
.finally { // this will run!
spinner.stopAnimating()
}
.catch { error in
// handle error
}Join different types of Promises seamlessly:
join(fetchArticle(id: "123"), fetchAuthor(id: "456"))
.then { article, author in
// ...
}Iterate over a sequence of elements and perform an operation each:
let articles = ...
map(articles) { article in
return favoriteService.like(article: article)
}.then { _ in
// all articles liked successfully
}.catch { error in
// handle error
}You can also iterate over a sequence in series using mapSeries().
Iterate over a sequence and reduce down to a Promise that resolves to a single value:
let users = ...
reduce(users, 0) { partialTime, user in
return userService.getActiveTime(for: user).then { time in
return partialTime + time
}
}.then { totalTime in
// calculated total time spent in app
}.catch { error in
// handle error
}Wait for all promises to complete:
all([
favoriteService.like(article: article1),
favoriteService.like(article: article2),
favoriteService.like(article: article3),
favoriteService.like(article: article4),
]).then { _ in
// all articles liked
}Easily handle race conditions with any, as soon as one Promise resolves the handler is called and will never be called again:
let host1 = "https://east.us.com/file"
let host2 = "https://west.us.com/file"
any(download(host1), download(host2))
.then { data in
...
}Start off a Promise chain:
// Prefix with Bluebird since try is reserved in Swift
Bluebird.try {
authService.login(email: email, password: password)
}.then { auth in
// handle login
}.catch { error in
// handle error
}Tests are continuously run on Bitrise. Since Bitrise doesn't support public test runs I can't link to them, but you can run the tests yourself by opening the Xcode project and running the tests manually from the Bluebird scheme.
I'd be lying if I said PromiseKit wasn't a fantastic library (it is!) but Bluebird has different goals that may or may not appeal to different developers.
PromiseKit goes to great length to maintain compatibility with Objective-C, previous versions of Swift, and previous versions of Xcode. Thats a ton of work, god bless them.
Bluebird has a more sophisticated use of generics throughout the library giving us really nice API for composing Promise chains in Swift.
Bluebird supports map, reduce, all, any with any Sequence type, not just arrays. For example, you could use Realm's List or Result types in all of those functions, you can't do this with PromiseKit.
Bluebird also supports Promise.map and Promise.reduce (same as Bluebird.js) which act just like their global equivalent, but can be chained inline on an existing Promise, greatly enhancing Promise composition.
PromiseKit provides many useful framework extensions that wrap core Cocoa API's in Promise style functions. I currently have no plans to provide such functionality, but if I did, it would be in a different repository so I can keep this one lean and well tested.
I began using PromiseKit after heavily using Bluebird.js in my Node/JavaScript projects but became annoyed with the subtle API differences and a few things missing all together. Bluebird.swift attempts to closely follow the API of Bluebird.js:
Promise.resolve(result)
Promise.reject(error)
promise.then(handler)
promise.catch(handler)
promise.finally(() => ...)
promise.tap(value => ...)Promise(resolve: result)
Promise(reject: error)
promise.then(handler)
promise.catch(handler)
promise.finally { ... }
promise.tap { value in ... }Promise(value: result)
Promise(error: error)
promise.then(execute: handler)
promise.catch(execute: handler)
promise.always { ... }
promise.tap { result in
switch result {
case .fullfilled(let value):
...
case .rejected(let error):
...
}
}These are just a few of the differences, and Bluebird.swift is certainly missing features in Bluebird.js, but my goal is to close that gap and keep maintaining an API that much more closely matches where applicable.
React
Typescript
Django
Laravel
Facebook
Microsoft
Google
Alibaba
D3
Tencent