
There's a lot of excitement about reactive programming in the front-end community:

- Angular [ships](https://angular.io/docs/ts/latest/guide/server-communication.html#rxjs-library) RxJS with Angular 2
- There's a [draft proposal](https://github.com/tc39/proposal-observable) to add an Observable to Javascript proper
- There's [a framework](https://cycle.js.org/) built entirely around the Observable
- React is most commonly used in [a reactive application structure](https://vincenttunru.com/Javascript-reactive-programming/#frp-today) together with [Redux](http://redux.js.org/)
- …and if not with Redux, then with the Observables of [MobX](https://mobxjs.github.io/mobx/)

Reactive programming is everywhere, so it's time we took a look at its primary concept: the Observable. What problems does it solve for us?

To answer this question, I will present three different metaphors that highlight situations that Observables can deal with elegantly. After this article, you should have a good idea of when to use Observables, and for what.

## Metaphor 1: Observables as special Promises

A [Promise](https://developer.mozilla.org/docs/Web/JavaScript/Reference/Global_Objects/Promise) is a data structure that represents a value that might not be immediately available. This is very useful when you want to perform some action as soon as that value does become available. An example use case is when you have made an HTTP request: at a certain moment, the response is going to come in, at which point you will want to perform some action. A Promise can then represent that eventual response.

A Promise could be described as such:

![A long arrow pointing to the right. At the far end at the right-hand side, a circle labeled "3" is located on the arrow, on top of a vertical line.](/img/3-metaphors-that-show-the-power-of-the-Observable/promise_marbles.png)

The arrow represents the passage of time; at a certain point, the promise is resolved with the value `3`.

### What can Observables do for me?

A Promise is useful if you're waiting for a single value, and want to perform an action when that value comes in. But what if you're waiting for multiple values? For example, what if you're waiting for user input, where you're waiting for multiple keypresses that drip in one by one?

This is where Observables come in. They can be seen as _Promises that can return multiple values_:

![A long arrow pointing to the right. On top of the arrow are, from left to right, three circles labeled "1", "2" and "3", respectively, followed by a vertical line.](/img/3-metaphors-that-show-the-power-of-the-Observable/observable_marbles.png)

The above is an Observable that, at different moments in time, delivers the values `1`, `2` and then `3`. Some time after that, it "completes": no more values are to be expected. This is indicated by the vertical line.

## Metaphor 2: Observables as a Design Pattern

Design Patterns are best practice approaches to common problems in software design. For example, the _Iterator_ pattern is a common approach to dealing with containers with multiple elements, e.g. lists of users. Your code can use an Iterator to get access to the container's elements, without needing to care about the container's implementation. 

![Schematic representation of an Iterator: a block of code with three arrows pointing to an Iterator. The arrows represent method calls to access elements from the container.](/img/3-metaphors-that-show-the-power-of-the-Observable/iterator.png)

Likewise, the _Observer_ pattern is a common approach when you have code that needs to become active when something happens elsewhere in the code. In this pattern, your code (the Observer) can register itself with a Subject, which will then notify it when the change has occurred.

![Schematic representation of an Observer: a block of code (the Observer) with an arrow pointing to it from a Subject. The arrow represents a method call on the Observer to notify it of an update.](/img/3-metaphors-that-show-the-power-of-the-Observable/observer.png)

### What can Observables do for me?

Whereas an Iterator is useful when you have a container with multiple elements readily available, an Observable shines when these elements might not yet be available. For example, when you need to call several REST APIs to collect all profile data related to a user, the different elements of the profile might arrive at different moments. Using an Observable, you can construct the full profile as the data rolls in.

Observables can be seen as a combination of the Iterator pattern and the Observer pattern. Whereas the Iterator is _pull_-based (your code "pulls" values out of the Iterator), an Observable is _push_-based: the Observable "pushes" values to your code as they arrive. 

![Schematic representation of an Observable: a block of code with three arrows pointing to it from an Observable. The arrow represents method calls on your code to provide it with new elements as they arrive.](/img/3-metaphors-that-show-the-power-of-the-Observable/observable.png)

## Metaphor 3: Observables as a way around shared mutable state  

Consider two functions that increment and decrement a counter, respectively:

```js
let counter = 0;

function increment(){
  counter++;
}

function decrement(){
  counter--;
}
```

In this example, both functions (shared) can change (mutable) the value of `counter` (state). This setup has some disadvantages, the most important of which is that it can make your code hard to follow. For example, you cannot simply look at the `increment` function in isolation: you have to keep track of every line of code that refers to `counter` and keep in mind how they can affect the function's code and vice versa. In the toy example above this is not a problem, but as your codebase grows, your code will become harder and harder to maintain.

A common approach to deal with this is to write your functions in a way that they do not depend on anything outside that function — so-called _pure_ functions. Rather than relying on the application being in a certain state, everything the function needs will have to be passed in as an argument. This results in functions that look like this:

```js
function increment(previousValue){
  return previousValue + 1;
}

function decrement(previousValue){
  return previousValue - 1;
}
```

The question then is: how we can know what the present value of the counter is, e.g. to show it to the user? You could store it in a variable which could then be updated like this:

```js
let counter = 0;
counter = increment(counter);
```

…but then we're back in the land of mutating state! If we want to show this value to the user, we still have to be aware of every line of code that references `counter` and might require updating the view.

### What can Observables do for me?

Observables provide a way to deal with changing values without having to resort to shared mutable state. Instead, you explicitly describe the way the value can change using pure functions. So to take our use case of showing the counter value to the user, we could simply subscribe to an Observable that delivers the new value of the counter as it changes, and use that to update the view.

![An application window showing a 3, the current value of the counter. An arrow pointing to the window is delivering the new values 2, 1 and 2, respectively.](/img/3-metaphors-that-show-the-power-of-the-Observable/mutation.png)

Let's say we have two buttons for incrementing and decrementing our counter, respectively:

```html
<button type="button" id="increment">Increment</button>
<button type="button" id="decrement">Decrement</button>
```

An Observable delivering the value `1` everytime the Increment button would look like this:

```js
const incrementClick$ =
  Rx.Observable.fromEvent(document.getElementById('increment'), 'click')
  .map(ev => 1);
```

Likewise for decrementing, but with the value `-1`. An Observable delivering counter values would then be constructed as such:

```js
const counter$ =
  // Create an Observable delivering 1 and -1 on
  // their respective button clicks:
  Rx.Observable.merge(incrementClick$, decrementClick$)
  // Emit a 0 before any button is clicked:
  .startWith(0)
  // Then add whatever is emitted (1, -1 or 0) to
  // whatever we had before:
  .scan((accumulator, value) => accumulator + value);
```

You can then subscribe to that Observable to update the view with the latest counter value:

```js
counter$.subscribe(counter => {
  document.getElementById('counter').innerHTML = counter.toString();
});
```

(You can view [the full working example at JSFiddle](https://jsfiddle.net/43me829w/).)

It should be noted that there are nothing but pure functions in the above example. There is no explicit variable holding the state, yet we are still able to display a dynamic counter value.

## What's next?

We've seen three different metaphors that helps us think about Observables:

- As Promises that can return multiple values
- As a Design pattern for containers that will have multiple elements, eventually
- As a way to represent mutable values without requiring shared mutable state

These metaphors provide insight into how Observables can be useful. As a next step, I'd recommend reading up on what you can do with Observables, and how they can help you structure your application. Coincidentally, I've written [another article](https://vincenttunru.com/Javascript-reactive-programming/) that deals with exactly that!

[![License](//i.creativecommons.org/l/by/4.0/80x15.png)](//creativecommons.org/licenses/by/4.0/)

_This work by [Vincent Tunru](https://vincenttunru.com/) is licensed under a [Creative Commons Attribution 4.0 International License](//creativecommons.org/licenses/by/4.0/)._


3 metaphors that show the power of the Observable


Here's a short public service announcement for those who write their tests using [Jasmine](https://jasmine.github.io/) or [Protractor](http://www.protractortest.org/): avoid [the `toBeTruthy()` and `toBeFalsy()` matchers](https://jasmine.github.io/2.5/introduction.html#section-Included_Matchers) and use `toBe(true)` and `toBe(false)` instead.

(Off topic: I've also seen people confuse Jasmine and [Karma](https://www.npmjs.com/package/karma). Karma fires up a browser to run tests in, but the actual tests are written using a testing library such as Jasmine.)

![](/img/toBeTruthy-vs-toBe-true/no_toBeTruthy_allowed.svg)

# What's the problem?

I've seen people using these matchers assuming they're just a weird spelling of `toBeTrue()` and `toBeFalse()`. But they're not: truthy and falsy [refer](https://developer.mozilla.org/en-US/docs/Glossary/Truthy) to values that are evaluated to `true` and `false` _after being [coerced](https://developer.mozilla.org/en-US/docs/Glossary/Type_Conversion) to a boolean_!

So yes, `true` is truthy, but `42` is _also_ truthy, and even `[]` and `'false'` are truthy! In fact, everything that is not `0`, `""`, `null`, `undefined`, `NaN` or `false` is truthy.

This means that if you're testing a function that errorenously returns `'false'` (a string) instead of `false` (a boolean), `toBeTruthy()` will match and `toBeFalsy()` will not.

So just like [you should never use `==`](http://eslint.org/docs/rules/eqeqeq), try to avoid `toBeTruthy()` and `toBeFalsy()`.

# So then what should I use?

Just use [the plain old `toBe()`](https://jasmine.github.io/2.5/introduction.html#section-Matchers) matcher to check for a value `toBe(true)` or `toBe(false)`, respectively. Unless you actually want your function to return different types of values, but even then I'd recommend you to change your code: otherwise, everywhere you're calling that function, you have to check for all possible return types.

[![License](//i.creativecommons.org/l/by/4.0/80x15.png)](//creativecommons.org/licenses/by/4.0/)

_This work by [Vincent Tunru](https://vincenttunru.com/) is licensed under a [Creative Commons Attribution 4.0 International License](//creativecommons.org/licenses/by/4.0/)._


toBeTruthy() will bite you — use toBe(true)



Javascript frameworks come and go -- by the time you have finished reading this post, three new frameworks will have been released. While it may sometimes look like they're just introducing more syntax to learn, the ones that actually get popular often introduce new paradigms that allow us to build features more quickly and with fewer bugs. We can learn a lot by taking a step back: where did we come from, and where are we now, in the year 2016? Which problems do the big frameworks solve, and which are left as an excercise for the programmer?

## At first, there was JQuery

![](/img/A-short-history-of-Javascript-frameworks-a-comparison-of-JQuery-AngularJS-and-React/jquery.svg)

With an easy-to-learn syntax, [JQuery](https://jquery.com/) led to the first bits of interactivity being added to our webpages. If you knew CSS, you knew enough to manipulate your webpage on the client side. Making a button click trigger the addition of a list item would typically look something like this:

```js
$('.button').click(function(){
    $('ol.todos').append('<li>New item!</li>');
});
```

No longer were full page refreshes necessary for every small change, and users rejoiced. That said, this style of programming can quickly become unwieldy. As an example, let's consider that we do not only want to show the new list item to the user, but also to save it somewhere. This requires that we keep an internal model of the list. In turn, whenever the list is modified, both the view and the model will have to be updated:

```js
let todos = []
$('.button').click(function(){
    $('ol.todos').append('<li>New item!</li>');
    todos.push('New item!');
});
```

It's easy to see how quickly this will lead to the introduction of bugs: as soon as the developer forgets to update the view when the model is updated, or vice versa, the user will be looking at incorrect data.

## Enter AngularJS

![](/img/A-short-history-of-Javascript-frameworks-a-comparison-of-JQuery-AngularJS-and-React/angular.svg)

Then, [Angular](https://angularjs.org/) came onto the stage, ushering in the era of actual web applications. It came with strong opinions on how to structure your projects, removing a lot of the error-prone paperwork that we now associate with JQuery. In Angular, your app's components consist of controllers and templates, with the former responsible for manipulating the state of your model and the latter for rendering it to the user. Thus, our little example now looks like this:

```html
<ol ng-controller="TodoListController as vm" class="todos">
    <li ng-repeat="todo in vm.todos">{{todo}}</li>
</ol>
```

```js
function TodoListController{
  let vm = this;

  vm.todos = [];

  vm.addTodo = function(){
    vm.todos.push('New item!');
  };
}
```

Angular eliminated a complete class of bugs: you can safely use `vm.todos`, and it would contain exactly the same list as the one the user is looking at. It quickly grew to be extremely popular, and continues to be widely used to this day.

That said, Angular isn't perfect either. Consider the case where we have two components: a list component, that renders a list of items, and a menu component, that allows the user to navigate through your app.

![](/img/A-short-history-of-Javascript-frameworks-a-comparison-of-JQuery-AngularJS-and-React/todolist.png)

How can we make sure the menu component knows about the number of list items? We can e.g. use the Angular concept of _services_: a single place to store your models, accessible by all your controllers. Our list controller might now look something like this:

```js
function TodoListController(TodoListService){
    let vm = this;

    vm.todos = TodoListService.getTodos();

    vm.addTodo = function(){
        vm.todos.push('New item!');
        TodoListService.updateTodos(vm.todos);
    };
}
```

However, this looks suspiciously similar to the problem we had with JQuery: we are now responsible for keeping things in sync again: the TodoList component's internal model and the service's model. This makes us vulnerable to bugs in which one part of your application displays data incongruous with that in other parts of your application.

An alternative approach would be to have your controllers manipulate the service's model directly. This tight coupling, however, comes with its own set of problems in which changes in one part of your application might have unintended consequences in others.

## React to the rescue

![](/img/A-short-history-of-Javascript-frameworks-a-comparison-of-JQuery-AngularJS-and-React/react.svg)

While Angular remains a popular choice for web applications, an alternative solution has quickly been embraced by a significant number of developers: the combination of [React](https://facebook.github.io/react/) and its trusty sidekick [Redux](http://redux.js.org/).

At the core of the style of programming that characterises this combination is the embrace of _immutable data_. Typically, a React component is merely a function that describes what, _given the state of your application_, your view should look like:

```js
state => view
```

To emphasize: the component does not alter your models (`state`), but merely defines what should be shown to the user (`view`). When our TODO list component is given an array of four items, its render function will return an `<ol>` containing four `<li>`s. When the same list is provided to our menu component, it can return the text `TODOS (4)`.

The advantage of not manipulating your models in your components, is that there is no risk in sharing the models between components. The menu component can safely access the model of the list, since it cannot manipulate it and thus cannot cause inadvertent effects in the list component. When the model is changed, the rendering function is simply called again with the updated model, and React makes sure that the new view will be displayed to the user.

Every component now always has access to an up-to-date version of our models, and so does our view. Redux helps you managing updating your models. You define the possible actions a user can perform, and a function that describes how those actions affect the state:

```js
(currentState, action) => newState
```

Again, note that this function uses immutable data: it does not modify `currentState` or `action`, but simply returns a new object `newState` that describes what the state should look like given the previous state and the action that was performed. (Apart from safe state sharing among different components, this also enables [other cool features](https://vincenttunru.com/Composing-Redux-reducers/).)

## What's next?

By taking a birds-eye view of the history of Javascript frameworks, we've seen what each brings to the table, and what problems they solve. Angular largely removed the need to keep your views and models in sync, and React/Redux gives us the ability to safely share our models between our components, while maintaing a proper separation of concerns.

While the idea of learning so many frameworks can be a bit too daunting, simply being aware of the new paradigms they bring to the table can go a long way. While React has seen rapid adoption, Angular is still going strong; thus, you can simply stick with Angular if you're comfortable with that. Nonetheless, the lessons taught by React can help be carried over to Angular, and are thus still useful to study.

No framework is perfect, and neither is React. In [my next post](https://vincenttunru.com/Javascript-reactive-programming/), I will look at a remaining pain point, and what trend is emerging to deal with it.

[![License](//i.creativecommons.org/l/by/4.0/80x15.png)](//creativecommons.org/licenses/by/4.0/)

_This work by [Vincent Tunru](https://vincenttunru.com/) is licensed under a [Creative Commons Attribution 4.0 International License](//creativecommons.org/licenses/by/4.0/)._


A short history of Javascript frameworks: a comparison of JQuery, AngularJS and React

This post is for people running into the following error when running a [Protractor](https://www.protractortest.org) test for their Angular apps:

> Error: Error while waiting for Protractor to sync with the page: {}

Many search results on the internet tell you that you can solve it by adding `browser.ignoreSynchronization = true;` to your code, with [a remark like](https://stackoverflow.com/questions/20059943/running-into-error-while-waiting-for-protractor-to-sync-with-the-page-with-basic):

> the key is to browser.sleep(3000) to have each page wait until Protractor is in sync with the project

Unfortunately, this usually is not what you actually want.

## How to solve it

Most of the time, the issue will be that you've added `ng-app` to a different element than the `<body>`, which is where Protractor guesses that your Angular app is located in the page.

You can use a different element, but you will have to tell Protractor which one. You can do so by specifying a [CSS selector](https://developer.mozilla.org/en-US/docs/Web/Guide/CSS/Getting_started/Selectors) referring to the element to the `rootElement` property of your [Protractor configuration file](http://www.protractortest.org/#/api-overview#config-files). A selector that will work most of the time is

```js
  rootElement: '*[ng-app]',
```

In other words, this tells Protractor to find Angular on the element with the attribute `ng-app`.

## Why does _ignore synchronization_ work?
Protractor runs on top of [WebDriverJS](https://code.google.com/p/selenium/wiki/WebDriverJs). WebDriverJS is a Javascript interface that let's you control browsers programmatically, which is useful for e.g. automatic tests.

So then... What does Protractor add? The problem in testing Angular apps using WebDriverJS is that [Angular has its own event loop](https://docs.angularjs.org/guide/scope#integration-with-the-browser-event-loop) separate from the browser's. This means that when you execute WebDriverJS commands, Angular might still be doing its thing.

One could work around this by telling WebDriverJS to wait for an arbitrary amount of time (i.e. 3000ms in the example above) and hope that Angular has settled down during that time. Of course, that wasn't pretty. Thus, Protractor was created to synchronize your tests with Angular's event loop, by deferring running your next command until after Angular has finished processing the previous one.

This is very nice and all, but becomes problematic when you're testing a website of which some pages are written in Angular, and some pages aren't. In the latter case, no matter how long Protractor waits, there is no Angular to complete its cycle -- in which case it will terminate with the error above.

Thus, *for non-Angular pages*, you can tell Protractor _not_ to look for Angular by setting `browser.ignoreSynchronization = true` -- which in practical terms will mean that you're just using WebDriverJS.

So by adding that to your configuration when Protractor cannot find Angular on your page, you're giving up on all that makes testing Angular apps easier than plain WebDriverJS. And yes, adding `browser.sleep` after all your commands will likely work, but it's cumbersome, will break as soon as Angular takes longer than the pause you set, and makes your tests take excessively long.

## The bottom line

- Use the [rootElement](https://github.com/angular/protractor/blob/master/docs/referenceConf.js#L187) property in your Protractor configuration.
- Only use `browser.ignoreSynchronization = true` when testing a page that does not use Angular.

[![License](//i.creativecommons.org/l/by/4.0/80x15.png)](//creativecommons.org/licenses/by/4.0/)

_This work by [Vincent Tunru](https://vincenttunru.com/) is licensed under a [Creative Commons Attribution 4.0 International License](//creativecommons.org/licenses/by/4.0/)._
