When JavaScript Gives You Lemons…

Make lemonade with Functional Reactive Programming

Marco Romero
5 min readNov 3, 2016

I am happy to see that Functional Reactive Programming (FRP) is becoming a popular option to develop scalable and maintainable web applications and services. But one of the problems that I see to get started for most people, is that there are very few entry level resources about the topic.

That’s why I decided to help you out to understand the core concept of the paradigm with this short story.

A Close Look to the Observable

So, the most important concept to understand to master FRP is the Observable/Stream. But…

Why Observable? Why Stream?

From the spec definition we get that it is:

A representation of any set of values over any amount of time.

The reason for the name “Observable” is because it represents something that can be observed…

…And that allows you to do stuff to it when something(an event) happens.

The other name, “Stream” is because it flows in time. It may have an end, or it may continue indefinitely.

Streams and Observables mean the same thing in FRP. They are essentially pipes that carry values originated from various event sources over time.

And like any piping, I can put a valve and pour out its contents and use them. In FRP land, that valve is a subscriber.

To make this more Observable to you, let’s make lemonade the FRP way. Also from now on I will be using only the word Stream as I think it expresses better the intent of flow over time thing. Also, I’ll be using most.js as my FRP library of choice. Why?

  • It’s the fastest FRP library available today.
  • Has a very simplistic and declarative API(IMHO).
  • It’s well documented and easy to extend.

Making the Most of a Lemonade

Imagine we have a lemon tree in our backyard and we managed to install a collector that every time a lemon is falls it gets sent through a pipe. Also we have our own water well that pumps a continuous flow of water to our house. And, we have a vendor that sends us sugar cubes through pipes… somehow, don’t ask.

imagine all the pipes…

The pipes that transport the ingredients are our Streams of materials. Each ingredient is emitted when something happens(an event) to our source(tree, well, vendor).

This is useful because you don’t know when an ingredient will be available, but you can know where it will be available.

MostJS comes with great utility functions to create streams from almost anything.

In code it will look like this:

In every interval of 1500 ms send a lemon, every 1000 ms water and sugar.

The “$” is a convention to express that the variable is storing a Stream.

Squeezing lemons

To make a lemonade you don’t require the whole lemons, usually you just need the juice from them. Seems like you could get the help of a juicer to get that…

adding a juicer

And in code:

Here is something very important that I want you to note.

It is possible to log out “lemons” and “lemon juice” after you used the juicer on the lemons stream.

This is because FRP streams follow the immutability rule. If you apply a transformation function (map, filter, reduce, etc) MostJS will not modify the original stream, instead, it will create a new one.

The main benefits of this are:

  • I can reuse the lemons$ stream somewhere else.
  • I get protected from shooting myself on foot with unexpected behaviours due to unnoticed side effects.

Mixing it up

Great! now you have what you need to prepare lemonade and start your own lemonade company. The only missing is to have a way to mix everything up. So let’s add a mixer to the piping model:

The coded version:

As you can see, this time you are able to connect all pipes and obtain a new one with the expected result.

This is the most powerful feature of reactive streams, they are very easy to compose, therefore easier to reuse across your app.

Here is another great thing you can do. Streams can listen to other streams and only pipe data under those conditions.

You wouldn’t like lemonade just spreading out without control all over your place right? so you will have to install a valve to choose when the liquid should be served:

The code speaks for itself. That’s the beauty of declarative API’s. From the lemonade stream take values since you get an open signal until you get a close signal.

And the full working example:

Closing up

I love doing stuff with reactive programming and I do understand the pain of learning this coding style since it requires you to think in a very different way than what most of us learned. But I think it is worth the hazel.

I hope that after reading and going through the examples you feel more confident about using FRP on your next project.

Here is also a list of other resources to deepen your knowledge:

Please give a recommend if you feel this writing was useful so other people can find it too. Also comments and feedback are always welcomed.

--

--