Transition to ReactiveCocoa v.4

If you have ever been interested in the ReactiveCocoa framework , you noticed that there are a small number of posts on the topic of reactive programming and the ReactiveCocoa framework, such as Introducing ReactiveCocoa , or Better World with ReactiveCocoa . Until today, all of these posts were on ReactiveCocoa 2 versions, which was written in and for Objective-C. Now the Swift language is gaining more and more popularity, the developers of ReactiveCocoa are working hard on a new version that will be written in Swift and will have some functional features that are fundamental to this language.

I suspect that many of you, like me, left Objective-C with a great desire and switched to Swift. If you would like to use ReactiveCocoa with a new language, I strongly recommend that you try using the new version of ReactiveCocoa. And I am sure that our community will greatly benefit from the contribution you have made. On the other hand, if you are working on large business applications in production for a specific customer, I must tell you - do not do this or think carefully before using it. But about this we will talk further, if you are interested in anyone - I ask for cat.

The status of ReactiveCocoa today

At the time of this writing, ReactiveCocoa (since this time referred to as RAC) is in an undefined state. When the first version of Swift was published, the developers began work on a third version of RAC. However, not so long ago, Apple released Xcode 7.0, which contains support for Swift language versions 2.0. This is caused by some critical changes in RAC3, but there are also some significant simplifications with respect to the new API. Changes pushed developers to start work on RAC4.
')
RAC4 is still far from being able to use it to create stable applications, but many are already doing this, and care must also be taken because the system changes frequently. The change log says - “Critical changes are possible, so be prepared for this before integrating it into the application.” But still, if you are really ready to experience RAC4, I will share some tips that will help you start using the new version of RAC.

Say goodbye RACSignal

In RAC2, all signals used the RACSignal type. The signal can be of two types - hot (hot) and cold (cold). A hot signal has at least one subscriber who processes events sent to it, it reminds me of a closed circuit that has no beginning and no end. A cold signal is one of the signals that may not have subscribers and therefore does not provide any action or information transfer. It can be divided into stages, the cold signal does not start its work until someone signs up to it.

RAC4 divides the concept of signals into two different types: Signal Producers and Signals. The signal procedure is very similar to RACSignal; the signal is inactive until it is started. The developers changed the terminology of the word subscribed to started, because this version describes this signal state more accurately. For example, the SignalProducer may have a plurality of subscribers that are subscribed to receive events, but the signal does not become active, and subscribers will not see any events until it is started for some reason. The signal is triggered by calling the start () method.

Another new type is Signal. Signal is like a fire hose. You connect it to the source and events flow through it. While there is no trigger signal, you can use it to work like a SignalProducer. Signals also do not support any history. When a subscriber subscribes to events from a signal, he will receive all future events, but no past events. Signals are very useful for transmitting information in real time, which occurs as a result of user interaction with the application. For example, a signal can send numbers and symbols that the user enters in a text field.

Defer method removed

You will also notice that RAC4 no longer contains a defer operation. Unlike a function call in RAC2, we will often use transfer blocks if we need to write a function that returns a signal, and also performs some other operations (like registering debugged text) when the signal goes hot.

The defer options in RAC4 no longer exist. To demonstrate this example, the authors suggest that we consider starting, like the following.

In Swift:

func logIn(username: String, password: String) -> SignalProducer<String, NoError> { return accountManager.logIn(username, password: password) .on( started: { print("Logging in...") } } 

unlike Objective-C

 - (RACSignal *)logInWithUsername:(NSString *)username andPassword:(NSString *)password { return [RACSignal defer:^{ NSLog("Logging in..."); return [accountManager logInUser:username withPassword:password]; }]; } 

MutableProperties

One of the features that I really like about RAC4 is the MutableProperty class. MutableProperty is a container for an object that changes during program execution. It also contains a signal initiator, which automatically sends each value that has been assigned to the subscriber.

Strong typing

The most difficult for me in the transition to RAC4 was getting used to the strong typing associated with signals. In RAC2, signals have no information about objects or errors. The restriction was only that all objects sent to them must be obtained from NS objects (not primitives). In RAC4, a signal is defined by this type for values ​​defined for it and for errors that can occur. For example,

 var signalA = SignalProducer<String, ReallyBadError> ... 

defines a signal that can only be sent to String objects, and only ReallyBadError can occur. Security in terms of types has some advantages in terms of what becomes clearer what information was sent, but at the same time it complicates the combination of signals.

In RAC2, you can easily take the signal that Bananas sends, connect it to the signal that Oranges send, and associate the result with the signals that Pineapples send. The resulting signal will not look proper, but the code will be compiled.

In RAC4, the compiler will show errors if you try to return signals that send Apples from a function that possibly returns a signal that Peaches are sending.

Signal combination

Combining signals is more difficult because the authors got rid of the good functions that used signal arrays to form linking, merging, etc ... For example in Objective-C, if you want to combine the two signals, you must do the following :

 -(RACSignal *) bakeCakeWith:(NSArray *)ingredients { RACSignal *preheatSignal = [self.oven preheat:@(350)]; RACSignal *bakeSignal = [self.baker combine:ingredients]; return [RACSignal concat:@[preheatSignal, bakeSignal]; } 

Now in RAC4, you must do the following.

 func bakeCake(ingredients: Array) -> SignalProducer<RACUnit, NoError> { let (combinerSignal, combinerSink) = SignalProducer<RACUnit, NoError>.buffer(1) sendNext(combinerSink, self.oven.preheat(350)) sendNext(combinerSink, self.baker.combine(ingredients)) return combinerSignal.flatten(.Concat) } 

But you can create your own function that will easily perform the same thing as in Objective-C.

I was definitely feeling a little disappointed when I got to know Swift and RAC4, but it was a really fun journey that I did. I plan to continue to move on, and I urge you to do the same.

Here are some really good sources where you can learn more about RAC:
Stanfy MadCode Meetup # 11: Why do you need to switch from Obj-C to Swift, or let's talk about ReactiveCocoa v4
An Introduction to ReactiveCocoa
MVVM WITH REACTIVECOCOA 3.0
Reactive Swift: upgrading to ReactiveCocoa 3.0