Hi @tuanback, thanks for reaching out; apologies for the delay.
Your absolutely right. Every asynchronous chain we discuss in the book could be replaced by
Singles and flap maps. And as you mentioned, the benefit is a reduction in dependencies. This is a great option if your team is going all-in on Rx. The good thing is, whether you’re using promise chains or
Single chains, the architectural structures that we cover in the book wouldn’t change.
I believe there’s no ‘correct’ way to approach modeling asynchrony. The decision should be based on tradeoffs. In the book, we chose to share a different approach. It’s the approach that has worked well for me and the teams I’ve worked with. I’ve faced a couple of challenges when trying to go all-in on Rx. For me, promise chains have been easier to read and work with than Rx chains. They’re easier to debug and reason about. But that’s my experience and that’s why I think this comes down to preference. Asynchrony is hard and is often the source of hard-to-fix bugs. If I can use a simple tool for 80% of the asynchrony code I need to write, I’d rather use the simple tool. The downside to this approach is that you still need to model streams of values over time. And for that, you’d want to use something like
Combine. So, you still have to learn a reactive framework. The difference is how often you need to reason and debug with reactive vs non-reactive frameworks. The idea is that you pay the learning cost only once but you pay the cognitive overhead every time you use a complex tool.
So I’d say the benefits to using PromiseKit are:
- Ease of use (easy to reason about and easy to debug) for 50-80% of typical iOS asynchrony needs
- Default threading model that is usually what you want
The downsides are:
- Paying the learning curve for both promise and stream based frameworks
- Additional dependency (although PromiseKit is a really small library)
You’re likely to encounter promise APIs, especially in other platforms. So I think it’s worth learning promises whether or not you plan on using them and it might be worth experimenting a bit with the two framework approach so that you can see the differences for yourself and make the decision that’s best for you and your team. Hope this helps. If there’s anything that wasn’t clear or if you have any follow up questions please don’t hesitate to ask. Cheers.