Why Swift Developers Should Be Using Reactive Programming
Changes happen all the time in the developer world. Sometimes it’s difficult to keep up with everything that is new. And as fast as things come, they become obsolete just as fast.
What was once considered standard practice, oftentimes is replaced by other methodologies and technologies.
Because of this, you must always be careful to not jump on the bandwagon too fast. Just because a lot of people are using a specific programming practice or a fancy new tool, doesn’t mean that you should follow the crowd. Whenever adopting a new practice, try to study it thoroughly first. Make sure you understand the problem it solves and any new problems it creates.
Why Swift Developers Don’t Need More Than MVC
Other architectures are fine, but MVC is all you really need
Reactive programming should be approached the same way. Before implementing this design pattern, you need to know the problems it solves, and how it can help you write better code.
This article is by no means a tutorial on how to use any specific library. Rather it’s to help you see why you should be using Reactive programming and some scenarios where it makes sense. In the future, I’ll be writing specifically about different aspects of the RxSwift library.
Makes Your Code More Readable
We all know about the closure nightmare in Swift. Because of the nature of mobile development, asynchronous processes need to be fired all the time. In the past, this was done mostly through the use of closures. Some of you may still be using mainly closures for this, and that’s fine.
But once you start having multi-nested closures. The nightmare begins. Reading and modifying multi-nested closures is a pain. A pain we’ve all experienced.
So how does reactive programming help lessen this pain?
With functions like map, flatMap and flatMapLatest, you’re able to chain observables. That way you can handle requests simultaneously without the difficult to read nested closure syntax.
Also, by using functions like merge, combine, and zip you’re able to execute multiple requests in a more readable and manageable way. And having readable code is essential to good development. The quote below helps us understand the importance of easy to read code:
“Indeed, the ratio of time spent reading versus writing [code] is well over 10 to 1. We are constantly reading old code as part of the effort to write new code. …[Therefore,] making it easy to read makes it easier to write.”
― Robert C. Martin, Clean Code: A Handbook of Agile Software Craftsmanship
So spending time making your code easier to read and understand is very beneficial.
Now, this doesn’t mean that you should abandon the use of closures altogether. That would be overkill. However, by using closures along with a reactive library of your choice, you can make your code more readable.
Helps With Event Handling
A common scenario in iOS development is the need to respond to events coming from different parts of the application. For example, perhaps someone changes their username on a SettingsViewController and we need to update their username on their ProfileViewController.
There are multiple ways of responding to events that happen in different areas of your app. There’s delegation, using notifications, and key-value observing. All of them work well. But Reactive programming has some benefits in this area as well.
For one, using reactive programming in these scenarios can be much more lightweight. All you need to do is create an observer or a subject and then subscribe to it. Then whenever that observer emits an object, whoever is subscribed to the observer will be notified.
The syntax would be something like this.
As you can see, this is very lightweight. It’s not overly verbose. And it’s not difficult to read. And as mentioned before, one mark of a great codebase is that it’s easy for anyone to read.
You can subscribe to the subject in as many places as necessary as well and do different things with the observer. For example, maybe you want to skip the first two elements emitted. You can use the skip function to do that. As mentioned above you can also combine observables using functions like merge and zip.
If you’re considered about coupling, then you can use a protocol and access the subject through the protocol. Something like this.
Makes Code More Modular
One of my favorite features of reactive programming is the ability to pass around observables as variables. This allows me to make my code more modular and readable.
For example, you can pass a network request to other objects and then execute that request whenever you see fit. This makes your code more modular.
You can have controllers that only require an observer of a specific type. Then you can send whatever network request you want to that controller as long as the observer emits the type it needs. I use this all the time when I have reusable controllers that display content to the user.
For example, something like Instagram where you have an object such as a Post object and you have one screen in charge of displaying Post objects to the user. You may want to display the Posts of the current user, or of a different user. Or Posts that the current user has liked. Or posts of those the user is following.
Since these are probably all handled through network requests, all you have to do is create the request as an observable and pass it to the controller. Then the controller will do the rest.
This code snippet should give you a general idea of what I mean.
So the advantages here are modularity and reusability. That one controller can be reused anytime you want to display a list of Posts. And all you need to do is send it an observer, making this controller completely self-reliant.
Overall, reactive programming can make your code more modular, more reusable, and more readable. If you’re familiar with MVVM, reactive programming is perfectly compatible with that architecture.
Whenever looking to implement new technologies or concepts, it’s important to understand why you should and are implementing them. I hope this article can help you understand the benefits of reactive programming, and see why you should think about implementing them in your next or current project.
The goal for your codebase is not to be fancy, but to follow good design principles. If developers have an easier time reading your code, you’ve reduced technical debt by reducing cognitive overload. (We’ll be writing about cognitive overload in a future article.)
When your code is more modular it’s easier to debug and to modify. When your code is reusable, it means you have to write less code. Less code means less complexity and fewer opportunities for bugs.
This is why I’ve adopted reactive programming, and I think you would benefit greatly by doing the same.
If you enjoyed this article, then clap for it. Some people don’t know you can clap up to 50 times for the same article. Try it!