A few days ago I was talking with an outstanding Senior Software Engineer about Reactive Programming (RP) and he told me that we did not need it; he said we already had Promises and they were enough. I have to say, it was not the first time I heard a developer say that, but I already knew why most of them say it. Very frequently we start learning a framework or how to use a library, without first understanding how the underlying programming language or associated technologies work and connect. I am seeing that most developers start the Angular journey without fully knowing and understanding things like Typescript or RP, or even JavaScript. I realized my fellow programmer associated RP and its main characters, Observers and Observables, to only making ajax calls to a server, retrieving the data and doing something with it. If you think this way, you will certainly associate RP with Promises and will say you don’t need another way to do that, and I will not blame you.

Once again, learning Angular without understating RP, and using it (RP) just to create services that retrieve data from a server, was making someone believe that that was all Observers and Observables were about. So I decided to create three simple challenges that I would have my friend solve using vanilla JavaScript and any other library or framework, except for RxJS, which I was going to be using for my solutions. I handed him the 3 challenges and said, “I would love to see you do it better and cleaner without Reactive Programming”, so he could have a glance at RP’s value or I could learn something even cooler. “One more thing”, I said, “you are free, of course, to use Promises”.

Please, include the next two lines of code at the top of your JavaScript file if you want to follow along, after having added a script tag to your HTML page pointing to https://cdnjs.cloudflare.com/ajax/libs/rxjs/5.5.11/Rx.min.js.

Challenge #1:

After clicking a button 3 times, with at least one second elapsed between each click, print “Challenge #1 solved” to the browser console once. Further clicks will not have any effects.

My solution:

We grabbed the button from the DOM using vanilla JavasScript, and then the magic began. We made the client event be an Observable, and we used three Observable operators to say, “Don’t emit a value if the previous one was emitted less than a second ago, wait for three emitted values to proceed, take only one and that’s it”. Finally, we subscribed an Observer that prints the desired result to the browser console when it’s notified of an emitted value. I will not get into any more specifics since the goal of this article is not really to explain RP, there are many articles about that out there already.

Think about this now, if you were to do this without RP, you would have to add a variable to keep track of the number of clicks, add some if/else and maybe use setTimeout (which you would have to manually clear because if you are dealing with a Production application, I know you don’t want your code to have the power to cause memory leaks). But guess what, I did not have to worry about any of those three things in my code, and I guarantee there are not bugs in it, how fast can you be sure of that in yours?

Challenge #2:

Make an ajax call to an API to fetch some data, retry the call up to 3 time in case of failure, but allowing 2 seconds to elapse between each ajax call. If the three calls fail, write “API call failed” to the browser console , if any of them succeed, show the retrieved data instead.

My solution:

The code is pretty self-explanatory. We create an Observable that represents the ajax call, and then we use several operators to delay each retry for 2 seconds, we only make 3 attempts, and if all of them fail we throw our error. Finally, we subscribe an Observer that knows how to handle success and failure. Think again, how much more code this would have taken without RP, and how much more error prone would that be.

Challenge #3:

Filter an array based on user input in a textbox as the user types, but wait one second before triggering the filtering, and display the filtered array in the browser console.

My solution:

We get the input element from the DOM, and make its keyup event an Observable. After that, we map over it to retrieve the text in the textbox after the user released the key. We then discard any value emitted in less than a second after the previous one was emitted, and restrict it from emitting again if the text in the textbox is the same than it was before. Finally, we subscribe an Observer that filters the array based on the current input and prints it to the browser console.

I have one interesting story related to the logic behind this last challenge. I saw a presentation once by someone working for Google where they were explaining how difficult it was for them to code the autocomplete feature for their product when they first had to do it. Something they thought was going to be very simple, turned out to be very complicated because they had to solve two interesting problems they were facing. The first one, triggering an ajax request to the server to get data after each key stroke was killing the application performance, and second, the nature of asynchronous programming was causing older results to override more recent results, creating a terrible user experience. If only they have had RP to write code very similar to this last one we wrote, having to just change the array filtering for the ajax call (and of course, handle some other real scenarios like failure or data display), it would have been way easier to complete the task.

Recently I heard Matthew Podwysocki, https://twitter.com/mattpodwysocki, say that he wrote code using jQuery to achieve some similar result (auto complete based on result of ajax call) and it took him two pages worth of code to do it. I do not doubt someone might be able do it in less than that, but I would love to see if it is better and cleaner than the RP solution.

If you are a server-side developer and believe RP does not apply to you, feel free to go directly to the last paragraph of my previous article https://medium.com/@ericrey85/functional-reactive-programming-explained-in-a-simple-way-in-javascript-yes-in-a-simple-way-925b14cddf75, or simply go to http://reactivex.io/, and you will discover you are incorrect.

If you would like to see another article with these three challenges solved using Functional Reactive Programming (FRP), please feel free to let me know through a comment or an email to ericrey85@gmail.com. If you would like to know first what FRP is about, you can read my previous article, which I already linked to in the previous paragraph.

End of the story, I was very happy to see that my fellow programmer fell in love with RP; although I have to confess, I really wanted him to come up with something that I did not know or imagine that was going to blow my mind away.

Happy coding!