What is Reactive Programming? In plain English, please.
Reactive Programming is a popular method for writing code that is based on reacting to changes. It’s inspired by our everyday life and how we take actions and communicate with others. When performing everyday life activities, we try to multitask when we can but the brain can’t multitask no matter how hard we try to have it do. The only way we humans can multitask is to switch tasks and split them efficiently during their lifetime. This makes more sense when the tasks that we need to do require some amount of waiting, which is almost always the case. We actually always switch-tasks, even when we’re not aware of it. For example, to execute the task of getting a coffee drink from Starbucks, you need to place an order, wait for it to be prepared, and then receive your drink. You’ll most likely find something else to do while you wait. I usually check my Twitter feed. This is the simplest form of executing a task reactively, you’ll do something else while you’re waiting on a “reaction” from the barista (to call your name when your order is ready).
Reactive programming is simply to program using, and relying on, events instead of the order of lines in the code. Usually this involves more than one event, and those events happen in a sequence over time. We call this sequence of events a “stream”. Think of events as anything that might happen in the future. For example, you know that Jane (a store owner) is always tweeting interesting stuff on Twitter, every time she tweets something we call that an “event”. If you look at Jane’s Twitter feed, you have a sequence of “events” happening over time (a stream of events). Reactive programming is named so because we get to “react” to those events. For example, imagine that you’re waiting for Jane to tweet a promotional code about something cool she sells in her store, and you want to “react” to that tweet, and buy the cool thing, using the promotional code. In a simplified picture, that’s exactly what Reactive programming is all about.
To be able to react to an event, we have to be monitoring it. If we don’t monitor the event, we’ll never know when to react to it. On Twitter, to monitor the events of Jane tweeting, we follow Jane and set our phone to notify us every time she tweets. When she does, we look at the tweet and make a decision if we need to further react to it or not.
In Reactive Programming, the process of monitoring an event is known as listening or subscribing to the event. This is, in fact, very similar to subscribing to a newsletter. When you subscribe to a newsletter on the Web, you supply your email address, and every time there is a new issue of the newsletter, your email address will be used as the way for you to get a copy of the issue. Similarly, we subscribe to an event stream with a function, and every time there is a new event, the stream will use the function to enable our code to react to the event. In this analogy, the newsletter platform is the event stream, every issue of the newsletter is an event, and your email is the function you use to subscribe to the event stream.
Now imagine a dynamic newsletter that allows you to select topics and send you only the news items that match your topics. You are basically filtering the newsletter issues to your liking, and that’s something we can do on event streams as well. Also imagine that you have subscribed to multiple newsletters using different email addresses, and later decided that you want all issues of the newsletters to be sent to a new single email address. One easy thing you can do is to set an email rule that forwards any issues from any newsletter to the new email address. You’re basically merging multiple newsletter issues into one email address, and that’s another thing we can do with event streams.
Another way to think about event streams is to compare them to regular arrays. They are actually very similar. Arrays are a sequence of values in space, while event streams are a sequence of values over time. In Reactive Programming, all the functional operations that we can do on an array — like filtering, reducing, mapping, combining, piping — can also be done on event streams! We can filter an event stream, reduce the values of an event stream, map an event stream to another, combine streams, and make one stream an input to another, among many other options that all yield a new stream of values over time.
Why can’t we just use arrays then, you might ask. The answer here is mostly about constraints, here are two examples:
- Event streams are ideal when we need to work with big amounts of data. Sometimes, for example, the amount of data we need to work with exceeds the amount of space we have, and working with regular data structures will not be an option. For example, imagine that we have to calculate the frequencies of characters in a 5 GB file on a machine that only has 4GB of RAM. Converting the file into a stream and reading chunks of data at a time will be a much better solution than loading up the whole file in memory.
- Event streams are also ideal when elements of data depend on previous values. Imagine, for example, that we need an array where every odd-positioned number has to be picked at random, and every even-positioned number has to be double the random value before it. Without Reactive Programming, we have to preprocess that array before we can have any code work with it, while with Reactive Programming, our array can simply be a stream of values over time, and whenever we have a new value we just react to it.
Our lives are full of events, and we naturally react to those events. That’s why I think the Reactive Programming pattern is an easier concept to understand and work with, and any code that’s written in a Reactive Programming style will be easier to maintain and extend.
I create online courses for Pluralsight and Lynda. My most recent courses are Advanced React.js, Advanced Node.js, and Learning Full-stack JavaScript. I also do online and onsite training for teams covering beginner to advanced levels in JavaScript, Node.js, React.js, and GraphQL. Email kyle@agilelabs.com if you want to book a session for your team.
This article was originally published here
