Introduction to Reactive Programming

NerdzLab
NerdzLab
Jul 22, 2017 · 6 min read

Hi! In this article, I will basically explain what reactive programming means, what benefits it brings and how not to shoot yourself in the foot while using it. The article mainly corresponds to the beginners level. If you identify yourself as a reactive God, then you won’t make much use of it.

So, what actually is reactive programming? If you ever tried to grasp the meaning of this phrase, you would find a lot of different and complex definitions which does not bring any clarity to the beginners. By the way, it happened to me at the dawn of my “reactive” road. Studying various approaches (e.g., functional or OOP) confused me even the more, and eventually, all that information became chaos in my head.

The first definition I got stated like this; that “reactive programming is the programming paradigm that operates streams of data and events on which your program reacts” and so forth. In spite of that, still, it was not clear enough for me to comprehend it.

At one point I thought that was not ready for such a “complicated” definition and should postpone studying it at a convenient time, i.e after I’ve become an App Architect. However, not long after, the eureka moment came and I understood that I only needed a simple explanation. That is why my goal here is to put this matter in simple terms and persuade you that reactive programming is really cool to use and will definitely bring a lot of advantages to your projects.

So then, let’s move on. Wikipedia provides the next definition: reactive programming — the programming paradigm, oriented on data streams and dissemination of changes across the program. That’s obviously not the best for the start, yet let’s give it a chance. I will try to express this interpretation in a more simple term.

Reactive programming is the programming, based on continual changes which usually lead to altering and binding objects. This way we get the chain of changes through the application. It is similar to the Observer design pattern (if you do not know it, check it out for sure), where the object that provides changes becomes a notifier and the triggered objects; observers. Moreover, triggered ones can also notify, which bring us to the conclusion that all objects are notifiers and observers at the same time. Finally, it simply comes to just binding of objects or actions.

Now, let’s try to understand Wikipedia’s statement bit by bit!

  • programming paradigm — this is an approach to building apps.
  • orientation on data stream — the chain that we create through objects’ binding. Admittedly, here we imply only the path for data transfer, but not the exact process of data transfer. This case can be compared to a water movement, where it flows from one point to another and creates a water channel, which in turn composes a water stream. Likewise, data also goes via data channels and streams.
  • dissemination of changes — dispersing data (sending notifications) across the program and from one object to another. That is actually water that flows between spots.

Besides, reactive programming stream can exist in three following phases:

  • Next — a stream has come to one of its possible states. In this situation, we receive a notification that our stream (in other words, our object) changed its status (its value).
  • Completed — a stream has reached its endpoint. The work with this channel is finished and it will not inform us any longer.
  • Error — a stream which does not work correctly and reports to us about some mistakes. For instance, a variable was not initialized properly.

Now you could certainly say that it’s not as hard as it seemed before, well I hope so too. The above was just a theoretical explanation. You would probably want to look at some practical points. Let’s try a simple reactive example. Some of you might have even tried it before, yet didn’t know it was a reactive approach. In addition, I want to remark that it’s not a pure, or, less to say, full reactive. This one represents just a simple part of it and gives a better opportunity to understand the process we are working with. So here it is…

class SomeController {  
var arrayOfData {
didSet {
someTableView.reloadData()
}
}
}

Now let’s describe what we got. We have an array of data with binded table view. You could observe reactivity with the “didSet” method. Supposing our array with data is substituted for another one, then our table view will be triggered for redrawing. Isn’t it the same thing we were talking about? A change in one object automatically leads to transformation of others. In our case, we mean table view.

Previously, I told you that this is not the pure reactive. The reason is pretty simple. If we remove an object from the array, it won’t lead to any effect. We could only alter the table view by changing the whole array. This indicates that our table view will not represent a real state of a data array, and overall binding logic is ruined.
But wait. How can we then use reactive in our iOS application?

In general, there are four possible solutions to it:
reloading methods as “willSet”, and previously discussed “didSet”. They’re quite easy to use, safe in coding, readable and apparently the best choice to start with. However, these methods do not cover all reactive needs. At some time, you will need a more powerful solution using notifications. On the one hand, it covers a more reactive area. On the other hand, UI binding is quite hard to work with. Besides, transferring data globally through the entire application has never seemed to be the best choice.

KVO — comprises of absolutely everything we need for reactive and supposing so works easily with UI. Nevertheless, this solution is unsafe for coding. Regarding lots of bindings in one class, I would not recommend using it in your applications, as your notification handling method will become enormously huge.

Using outside libraries — perhaps, the best of all methods. It ensures less coding (even less, as compared to the standard approach). The coding becomes readable, flexible to change, and safe, or in simple terms, with less amount of bugs. In spite of cool advantages, this method has some uncool demerits. Though it does not apply to native libraries, there is no guarantee that they will be supported in the future. Consequently, I will not advise using it in bug problems. But then, I think it’s worth risking it.

Frankly speaking, we shouldn’t waste our time studying the first three solutions. The last one is rather more peculiar. Obviously, these libraries are not native and probably most of you won’t even know how they operate. Starting a new project without an in-depth knowledge of libraries would definitely lead to fiasco. Just imagine a monkey with a grenade. So let’s figure out how they work, using RxSwift library as a role model.

Why did I exactly choose this one? First of all, it is written in the Swift language, what makes it more desiring and more clear is due to its powerful language mechanism. Secondly, confidence in support staff and stability are guaranteed as it was implemented by a famous RX library builder. And lastly, the RxSwift library is one of the most popular tools nowadays. So then, let’s proceed!

NerdzLab

Written by

NerdzLab

For ideas never seen before. https://casestudies.nerdzlab.com/

Welcome to a place where words matter. On Medium, smart voices and original ideas take center stage - with no ads in sight. Watch
Follow all the topics you care about, and we’ll deliver the best stories for you to your homepage and inbox. Explore
Get unlimited access to the best stories on Medium — and support writers while you’re at it. Just $5/month. Upgrade