The vision of Functional Reactive Programming (FRP) and specifically ReactiveCococa (RAC) 4.0 alpha are both impressive. FRP via RAC and Swift feels right. As mentioned in my previous article, RAC 4.0 is useable. Its core concepts are quite solid. Yet, one has to really want to dive in and be willing to offset any UIKit shortcomings. That’s fair since RAC 4.0 is alpha.

Where ReactiveCocoa needs more help:

• There is a need for the ReactiveCocoa CocoaPods spec to be updated
• There is a need for more UIKit extensions

Need for Updated ReactiveCocoa CocoaPods spec

That’s probably easy for one to do since it’s an update to an existing pod spec. If one doesn’t have time or want to, one can use Carthage as mentioned in my previous article, Swift 2 ReactiveCocoa MVVM Quest.

More UIKit Extensions

Based on a post here by Neil Pankey (a collaborator on ReactiveCocoa), Rex is a ReactiveCocoa Extensions project that eventually will get merged into ReactiveCocoa. As Neil mentions:

It’s not there yet, because “..haven’t found the time to port them, flush out the missing properties, add documentation, etc”

Although it has some extensions, more are needed. I immediately came up for the need for an extension that would let me capture text in a UITextField. Digging deeper I see in a somewhat older post, that there are many extensions that need to be ported over to Swift. Looking at Rex UIKit specific code myself, I think that’s still the case. If the community rallies around making more UIKit Extensions, it would help everyone.

To address what I needed now, I used a fork of ReactiveTwitterSearch originally made by Colin Eberhardt, and grabbed the UIKitExtensions code and a couple other items. Doing that, I was able to bind the text put into a text field straight into a View Model like so:

        loginViewModel.username <~ usernameTextField.rac_text

That line of code is quite similar to the awesome but dated article RAC 3 Properties section of MVVM with ReactiveCocoa 3.0.

So, that is neat and powerful since with some easy to read binding/configuration one is making it much easier to do MVVM. As long as you don’t mind, piecing things together and absorbing the learning curve, this power is yours for the taking now.

The Quest

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.

Success!

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!