Demystifying Functional Reactive Programming

ReactiveX and similar libraries for reactive programming get sometimes labelled “Functional Reactive Programming”, but actually this is not quite right.

ReactiveX is reactive and it employs many elements known from functional programming such as anonymous functions and methods such as map, filter and many others.

However, Functional Reactive Programming has been clearly defined as something else.

As the documentation of ReactiveX puts it:[ReactiveX] is sometimes called “functional reactive programming” but this is a misnomer.

ReactiveX may be functional, and it may be reactive, but “functional reactive programming” is a different animal.

One main point of difference is that functional reactive programming operates on values that change continuously over time, while ReactiveX operates on discrete values that are emitted over time.

Functional Reactive Programming was defined originally more than 20 years ago by Conal Elliott and Paul Hudak in their paper Functional Reactive Animation.

They made a distinction between “behaviours” and “events”.

Events are basically like the streams we looked at earlier.

They are “discrete values that are emitted over time”.

If you put them in a chart, they will look like this:EventsBehaviours, however, are continuous values that change over time.

This is a subtle but important difference.

If you put a behaviour in a chart, it will look like this:BehaviourA behaviour always has a value.

An event only has a last occurence (and maybe an associated value).

So, for example, the position of a mouse is a behaviour because you can ask for its current position.

Mouse clicks, however, are a stream — you cannot ask for the current value of a mouse click, only for its last occurence.

ReactiveX only models discrete events but no continuous values.

So how come it gets away with it?It is possible to abandon the distinction altogether.

When asking for the value of an event, you can simply take the value of its last occurence.

When having a continuous behaviour like a mouse movement, you can sample it and treat it like an event stream.

However, this can leed to a bunch of problems.

For instance, it is possible to combine event streams by simply adding the events from the one stream to the other, but this doesn’t make sense for continuous values.

(Maybe you can sum up the values of two behaviours if this makes sense in your application, but that’s a different thing than adding the events of one stream to the timeline of the other stream.

) If you don’t make a distinction in the API, there is no way for the API to prevent you from doing something stupid.

If you’re interested in a more extensive discussion on why the distinction makes sense, I recommend this article.

To get back to our original example of a worksheet with a cell summing up the values of two other cells: The values of the cells are behaviours.

They always have a current value and the value of the cell calculating the sum depends on the values of the two other cells.

On the other hand however, if you change the value of a cell, this change is an event.

If you now wanted to write a worksheet application, you could go about it in two ways: You could attach a callback to the change-event to update the value of the sum.

However, if another value depended on that sum, you would need to attach another callback to that as well.

You can see how this can become unwieldly pretty quick.

On the other hand, you could model the cell values as behaviours, where the value of the sum is a function of the two other values it depends on.

This seems like a more natural approach to solve this problem that would lead to code that is more elegant.

I’m planning to write a few articles on how to write a little scala framework to do something like that in the near future, so stay tuned.

I hope this article gave you a better understanding of all the buzz words surrounding functional reactive programming.

Obviously, I could only scratch the surface in this article and there is much more to functional programming, reactive programming and functional reactive programming.

If you want to dig deeper, here are a few articles I can recommend:Reactive programming vs.

reactive systems: https://www.

oreilly.

com/ideas/reactive-programming-vs-reactive-systemsThe introduction to reactive programming you’ve been missing: https://gist.

github.

com/staltz/868e7e9bc2a7b8c1f754An Introduction to Functional Reactive Programming: https://blog.

danlew.

net/2017/07/27/an-introduction-to-functional-reactive-programming/ (the view on functional reactive programming differs a bit from mine, but nevertheless a great article)If you have any suggestions or feedback, let me know in the comments!.

. More details

Leave a Reply