Just last week I was fortunate enough to be able to attend a workshop on Angular 2 and RxJS. I had a really great time and can say that I am really interested to learn more about what Angular 2 is doing. (Which might surprise many of you who know I generally prefer other frameworks to Angular)

What I most took away from the workshop, however, was a strong desire to dive deep into RxJS. I have played with it a little in the past but I've decided it is long past time to dive deep.

In laying the foundation for this exploration I wanted to overview the two design patterns which RxJS has combined. These are the observer and iterator patterns.


The observer pattern should be familiar to anyone who has worked in front-end development(and probably many other areas which I am not as familiar).

The basic concept is that observers register themselves to a subject and are notified of changes on that subject. They are then able to decide whether they want to act on that notification based on their internal logic. Anyone want to addEventListener?

For anyone who is somehow unfamiliar a basic implementation of a subject might look like this:

function Subject() {
  this.observers = [];

Subject.prototype.addObserver = function(observer) {

Subject.prototype.removeObserver = function(observer) {
  let i = this.observers.indexOf(observer);

Subject.prototype.notify = function(event) {
  this.observers.forEach(observer => observer.update(event));

Pretty straight forward. The subject is an object which keeps a list of interested parties and pushes event notifications out to them.


The iterator, rather focusing on the handling of single events, deals with sequences.

Specifically an iterator gives the program a way to, well, iterate, or traverse, a sequence and access the values in order. You might think of an iterator as a lazy evaluating for-loop.

Unfortunately, it wasn't until ES2015 that Javascript got native support for custom iterators. The spec only provides for a .next method with which to call the next value. However, in practice iterators are more useful when built with the richer ability to act on their collection.

Here is an example of an iterator which will return the next string which is shorter than a given length or each strings if no length is provided:

function Iterator(array, length) {
  this.index = 0;
  this.arr = array;
  this.len = length || INFINITY;

Iterator.prototype.next = function() {
  while(this.index < this.arr.length) {
    const string = this.arr[this.index++];
    if(string.length < this.len) {
      return string;

Iterator.prototype.hasNext = function() {
  var i = this.index;
  while(i < this.arr.length) {
    if(this.arr[i++].length < this.len) {
       return true;
  return false;

Why Rx?

At this point you might be asking yourself why would reactive extensions want to combine two patterns that are so clearly different? The observer pattern pushes data to the receiver and is focused on individual events. The iterator pattern leaves the user to request data and is built to handle sequences.

Well it turns out that reality usually involves an interesting intersection of the two of these. If you consider a user of an application, they don't use that application as a single event. They also don't generally want to wait around for an application to pull information from them, they push their interactions at the application.

At a high level you can think of a users experience with an application as being a sequence of events or data points pushed to the application. That's why Rx.

If it's not enough for you consider this. It's a beautiful experience to right reactive code. While again, I have only dabbled at this point, it's easy to see how RxJs allows you to write more well composed and declarative code. And that is a beautiful thing.