Pod Review 👏 👏 : PromiseKit
Today we kick off the series with a popular one — PromiseKit. Its Github repository sits at just over 10,000 stars at (the time of writing) with its first release being in early 2014. It’s fair to say it has its supporters.
It promises (ha-ha) to simplify asynchronous programming. This article will cover the more common usages and evaluate factors such as documentation, ease of use and how much of an impact it can have on your project, before giving a final verdict on whether PromiseKit fulfils its goal and if you should consider including it in your next app.
A common problem: Callback Hell
The example above shows only a few levels of nesting. Now imagine if we wanted to do more asynchronous operations after that — a recipe for disaster.
The PromiseKit solution.
Below is the un-refactored version.
Instead of using escaping closures in the function, we return promises. Promises will either fulfill with the required result or throw an error, which is caught in a separate closure. The seal within the Promise is in charge of handling the success and failure cases. You can call fulfill, reject or resolve on the seal.
You might think at first: ‘well this looks like a lot more code, and it looks quite complicated.’ It is true that PromiseKit does have a learning curve, but once you get used to using it, you’ll discover that the example above can be refactored into something that looks like this:
Above uses the firstly keyword and the then function (both supplied by PromiseKit) to allow for easy chaining of Promises. The need for a seal here is eliminated here and we can clean up some of the excessive nesting.
or you can go even further and refactor it into this:
You can see that the readability of the code has improved drastically when compared to the closure nightmare.
The example above only scratches the surface of what PromiseKit is capable of, but after working with it for a few months, you’ll discover how much it will clean up your code, decrease debugging time and make your solution more adaptable.
In PromiseKit, a lot is going on under the hood, so you get some things for free:
• Function chaining: no more nesting, escape callback hell and chain promises to your hearts content!
• Error propagation: Handle all your errors an organized way. PromiseKit will warn you if something isn’t.
• Generics: Using the power of generics and compiler inference, you can reduce code, and write complex tasks cleanly.
• Threading: You can control what thread a promise executes and completes on.
• Memory Management: PromiseKit handles a lot of the memory itself, so it reduces the need for capturing weak self.
Why not PromiseKit?
PromiseKit does have some caveats, though:
Promises can only be fulfilled once, so they can’t be ‘reactive’ like escaping closures. If you want to use PromiseKit, it is your best bet to integrate it throughout the entire project. If you’re already well into the development phase of your app, or you are working with some other data binding library, PromiseKit might not be for you.
It also requires some existing Swift knowledge; If you are an absolute beginner, I would recommend looking at the standard way Swift handles asynchronicity, in addition to the basics of generics before moving on to a Pod such as PromiseKit.
The documentation is thorough with examples. The Pod receives regular updates, with detailed migration guides included. PromiseKit works with Objective C and Swift. You can find the repository here.
Verdict: Gamechanger
If your app has a lot of asynchronous logic and you have no organized, uniform solution to handle results and propegate errors, or you’re just sick of writing escaping closures, then I would strongly recommend PromiseKit.
