For a software developer (especially at CARFAX), the quest for cleaner code is worthy and eternal. In Swift and Objective-C, two main battlefields where clean code is threatened are View Controllers and client network code. View Controllers get big and client network code suffers from the Pyramid of Doom. The Pyramid of Doom is where there are many nested statements as shown in this Traditional asynchronous code slide. Following the advice of a smart friend named Mike Groner, I looked into ReactiveCocoa (RAC) and revisited MVVM.
Since we have looked at MVVM before and MVVM’s roots go way back to the Presentation Model via Martin Fowler, its concepts are not foreign. It’s true that one does not have to use RAC to do MVVM. As Natasha The Robot showed in her Swift Summit presentation and related Protocol-Oriented MVVM (POMVVM) article, one can manually follow the discipline of doing POMVVM without a framework. So, that’s great. One concern is that it requires the team to relentlessly apply discipline to do POMVVM well.
Shifting our attention to the Pyramid of Doom, how can RAC and Functional Reactive Programming in general help? To answer that question, I checked out Javier Soto‘s Back to the Futures Swift Summit presentation. It was eye opening. It discussed how we typically handle asynchronous callbacks (thus the Pyramid of Doom), error handling, and the concept of Futures as a way of getting rid of “…all the noise related to the asynchrony itself.” Easier to write, read and maintain code through Futures / Promises or better yet Signals sounds good! At the end of the talk, he also recommended ReactiveCocoa aka RAC.
So, What About ReactiveCocoa (RAC)?
OK. The message is loud and clear: Check out RAC! Natasha-The-Robot, guided me to Ash Furrow. Ash helpfully shared Functional Reactive Awesomeness With Swift So, RAC is impressive and RAC may even help one do MVVM. Which version of RAC should I investigate?
For an upcoming project, using Swift 2.1 is a no brainer. Can RAC or something similar be used in a Swift 2.1 project? NachoSoto comes to the rescue on Twitter and Stackoverflow: How to Add Production Ready ReactiveCocoa … Into Swift 2 iOS. So, the answer is yes!
Getting ReactiveCocoa 4.0
Being more than ready to dive into ReactiveCocoa 4.0, the question was now “how to get it?” I tried using CocoaPods, but the unofficial podspecs were out of date. it seems like a good answer is using Carthage with a Cartfile of:
github "ReactiveCocoa/ReactiveCocoa" "v4.0.0-alpha.3"
Since I have been a CocoaPods user, it didn’t immediately occur to me to copy the frameworks as per the RAC README page:
On the “General” tab of your application target’s settings, add ReactiveCocoa.framework and Result.framework to the “Embedded Binaries” section.
RAC and MVVM?
Could RAC or something like it also help with MVVM? Both my friend and Ash Furrow’s presentation above suggested that it could do so beautifully. Searching the web for the most recent ReactiveCocoa Swift examples, I found MVVM With ReactiveCocoa 3.0 by Colin Eberhart and Migrating to Swift 2 and ReactiveCocoa 4 by Martin Richter. So, it certainly seems so.
With ReactiveCocoa 4.0 and examples at hand, the journey has just begun and the quest for clean and well crafted code continues!