I’ve been recently looking into reactive programming and I’ve realized that all reactive programming [0] can be reasoned about as a scan operation. It seems like this fact is somewhat known to people who have been doing reactive for some time (AFAIK it’s the core of the redux pattern) but I feel like this fact needs to be highlighted since it’s important for developing intuition about reactive programming (or at least it was for me). Note that this blog posts assumes some understanding of reactive [1].

What’s scan?

If you are not familiar with scan, it’s a higher order function that’s fundamentally similar to reduce but unlike reduce, returns all the intermediate accumulator values. It’s present in Haskell and can be implemented in Swift as follows:

Note that in reactive, scan and reduce functions are somewhat different compared with their ‘non-reactive’, functional counterparts because all computation is spread over time as events are arriving from the observable.

For this reason, in reactive programming, you can’t really use the reduce function on an infinite stream since you don’t have access have access to the last value of the stream (it hasn’t been generated yet). So you use scan instead instead.

In reactive, scan is basically reduce executed over time.

The way scan ties the whole paradigm together is as follows:

the entire application state is represented as a single structure

the I/O events (user/hw) are coming from an event stream

you put all logic in the combine (+) [2] function, where you combine the current state and the new event to create a new state

in the [2] function, where you and the to state keeps getting updated as long as the stream keeps generating events

Scan is the function that drives this whole process.

Expressed more formally [3], scan repeats the following operation:

state’ = state + event

Expressed in code:

And with an example [4]:

This leads me to believe that scan is THE pattern of reactive programming, since it drives the whole operation [5].

This brings us to an important question. Isn’t scan like the fundamental operation of all programming (not just reactive) since most programming needs to deal with state and events? I believe that the answer is yes (at least for any “real world” definition of programming) but you might have to wait for the next blog post to see that this pattern actually cuts much deeper into the entire programming field.

You might also be interested in this this book.

It’s not perfect (as the reviews hint) but most other books on the subject don’t deal with reactive in the UI layer and this book actually builds a somewhat larger application which is fundamental to understanding new tech.

[0] By reactive programming, I don’t mean true FRP but programming that reifies events. Similar to the interpretation by the ReactiveX community.

[1] Check out this if you need some intro to reactive. Btw I think that RxSwift is one of the best language/platform combinations to get started with reactive these days, the project has an associated Swift Playground. Learning a new stack that doesn’t have something like Playgrounds will seem like some primitive technology after experiencing this. But learning it in Javascript also has it’s advantages.

[2] We can call this function, idk, +, since you know, we are combining things, kind of like a plus does.

[3] Wow, is that a formula? State prime? Let me get my big boy pants, we are getting serious up in here.

[4] A simple counting app is the default reactive example it seems, the “hello world” of reactive. I’ll let you draw the conclusions yourself, but I’m curious to hear what do you think this means.

[5] Note that we’ve fundamentally implemented a program that is run in an event loop without having to deal with the event loop. We’ll talk more about event loops and why they are dank in some later post.