

Previously, [I took a look at the current state of Javascript frameworks](https://vincenttunru.com/2016-javascript-framework-overview/). Today, I will take a look at what I think will be the next frontier of front-end programming: functional reactive programming.

## (Functional) Reactive Programming

Reactive Programming revolves around the use of a data structure representing asynchronous data, called _observables_ or _streams_. You could compare them to [Promises](http://www.html5rocks.com/en/tutorials/es6/promises/).

![A promise returning the value 3](/img/Javascript-reactive-programming/promise.png)

(Diagrams are courtesy of [RxMarbles.com](http://rxmarbles.com). The arrows represent time.)

Roughly speaking, promises represent a value that might not be known when they are first used, but might arrive any moment. Observables are similar, except that they represent the potential arrival of multiple values.

![An observable returning the values 1, 2 and 3, in that order](/img/Javascript-reactive-programming/stream.png)

Observables are great for representing related values arriving asynchronously, such as characters entered into an input field.

When we use functions that take observables as input and produce a new observable as output (i.e. [pure functions](https://en.wikipedia.org/wiki/Pure_function)), we are doing what is commonly referred to as _Functional Reactive Programming_. There are many Javascript libraries providing commonly used operators, such as [RxJS](https://github.com/Reactive-Extensions/RxJS), [Bacon.js](https://baconjs.github.io/) and [Kefir](https://rpominov.github.io/kefir/).

These can be simple operators like [`delay`](http://rxmarbles.com/#delay), that simply returns a new stream that produces the same values as the input stream, only with a slight delay.

![Example of `delay`](/img/Javascript-reactive-programming/delay.png)

The operators might use the actual values produced like [`map`](http://rxmarbles.com/#map), which returns a new stream that produces the values of the input stream after being passed through a given function.

![Example of `map`](/img/Javascript-reactive-programming/map.png)

Previous values could also be used, like in [`scan`](http://rxmarbles.com/#scan), which produces an accumulator using a given function (similar to the [`reduce`](https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/Array/Reduce) function you might know already).

![Example of `scan`](/img/Javascript-reactive-programming/scan.png)

They might even combine multiple streams like [`merge`](http://rxmarbles.com/#merge), which returns a stream that produces all the values produced by its input streams.

![Example of `merge`](/img/Javascript-reactive-programming/merge.png)

One you get used to them, observables can greatly simplify dealing with asynchronous data. For example, consider a situation where you have two input fields, and you want to check whether both of them have a value. When you have observables `field1$` and `field2$` (convention is to denote observables by appending a `$`), you can use RxJS to create a stream that emits a new boolean every time the form changes validity:

```js
const isValid$ =
  Rx.Observable.combineLatest(field1$, field2$)
  .map(fields => fields.every(field => field.length > 0));
```

(You can see it in action in [this fiddle](https://jsfiddle.net/vhb4jcw9/).)

This might be difficult to parse the first time you read it, but once it clicks, working with asynchronous data becomes far easier with observables in our toolbox. Note that the above approach easily scales to however many form fields you have.

An additional benefit is that it steers you away from a whole class of bugs. To illustrate: consider trying to do the above using a more traditional approach. We would likely [create an event listener to check the validity of the form](https://jsfiddle.net/tn32yvmm/) when the user enters input:

```js
function checkValidity(){
  return document.getElementById('field1').value.length > 0 &&
         document.getElementById('field2').value.length > 0;
}
```

We wouldn't be the first to attach the event listener to the final form field and be done with it. We fill in the form, see the validity update, and conclude that it works. After deployment, however, some users will fill out the form, and then go back to the first field and clear its contents. Surprise: our form will still claim that it's valid. We forgot that the event handler also had to be attached to the other form field.

Obviously, what with you being the perfect programmer, this wouldn't happen to you. But by using observable, such errors would be really easy to spot. When your less gifted colleague adds is tasked with adding a form field, there's only one place it needs to be added: the combined form stream. It will then just work, validation included, as the data flows directly from the form fields into the validation.

There is much more to Functional Reactive Programming than this, and fully wrapping your head around it might take some time. If you're interested, you might want to try [Getting Started with RxJS](https://github.com/Reactive-Extensions/RxJS/tree/master/doc#getting-started-with-rxjs).

## FRP today

If you're as excited about FRP as I am, you're in luck: it's already gaining a lot of headway.

Consider, for example, the combination of React and Redux I touched upon in [my previous post](https://vincenttunru.com/2016-javascript-framework-overview/). With Redux, you describe how your application's state evolves in response to user actions with a function of the form `(currentState, action) => newState`. You then use React to describe what view that state should result in with a function of the form `state => view`.

Wait a minute... If you squint hard enough, that looks just like manipulating an observable with the [`scan()`](https://github.com/Reactive-Extensions/RxJS/blob/master/doc/api/core/operators/scan.md) and [`map()`](https://github.com/Reactive-Extensions/RxJS/blob/master/doc/api/core/operators/select.md) methods!

![React/Redux's architecture modelled](/img/Javascript-reactive-programming/react_architecture.png)

This is a very limited reactive system. In essence, all asynchronous input to your application will have to be converted to that one observable for actions. This can get quite awkward for asynchronous input that isn't exactly a user action, such as HTTP requests. This often leads to workarounds such as [emitting multiple actions](http://redux.js.org/docs/advanced/AsyncActions.html), e.g. one when a request is sent, and another when the response comes in. [Several libraries have arisen](https://twitter.com/dan_abramov/status/689639582120415232) that claim to make it easier, but all of them are bound to that single stream.

A Redux alternative called [MobX](https://mobxjs.github.io/mobx/) is also gaining ground, providing an implementation of observables to model component state. I haven't looked into it too deeply yet, but it appears to distinguish itself from Redux mainly by enabling components' local state to be modelled as observables as well, whereas Redux only supports a single place to hold all your application state.

On the Angular side, the developers have decided to [endorse and use RxJS](https://angular.io/docs/ts/latest/guide/server-communication.html#!#rxjs) for the major rewrite that they are currently completing. They're using it for HTTP requests, the planned router [is using it as well](http://blog.thoughtram.io/angular/2016/06/14/routing-in-angular-2-revisited.html), and you can pass them to your view templates [for more efficient rendering](http://victorsavkin.com/post/110170125256/change-detection-in-angular-2). That said, user input is still handled through callbacks, and in practise, many Angular apps will likely apply none or few transformations on their observables before passing its values back to regular callback- and promise-based code.

## A glimpse of the future: Cycle.js

The first steps toward wider adoption of FRP have been taken, and they don't seem to be stopping any day soon. So where will this bring us?

One framework that is worth looking into in this regard is [Cycle.js](http://cycle.js.org/). Cycle applications are conceptually simple: all they do is convert a series of input streams (_sources_, in Cycle terminology) to a series of output streams (_sinks_). These input streams are provided by what Cycle dubs _drivers_, and the output streams are fed back into those drivers. The values emitted to the output streams are descriptions of the [side effects](https://en.wikipedia.org/wiki/Side_effect_(computer_science)) you want to happen, and the drivers actually execute them, looping potential results back into the input streams. These drivers are usually small, separate libraries tailor-made to perform a specific side-effect in response to incoming observables, and to deliver any potential outside values through observables as well. A consequence is that the app itself is side-effect free, making it easy to reason about and easy to test.

Let's illustrate this with a very simple example application.

![](/img/Javascript-reactive-programming/cycle_lifecycle_app.png)

To be able to show something to the user, we output a description of what we want the DOM to look like onto the DOM driver's output stream. The DOM driver will then apply those changes to the DOM.

![](/img/Javascript-reactive-programming/cycle_lifecycle_render.png)

Likewise, the DOM driver also provides input streams that contains user input. Which can, in turn, be a trigger to push new DOM descriptions onto the output stream and thus update the view.

![](/img/Javascript-reactive-programming/cycle_lifecycle_input.png)

User interaction is only one type of side effect though. Another commonly used driver is the HTTP driver. By pushing values onto the output stream to the HTTP driver, apps can send HTTP requests, and the accompanying responses will be pushed onto the corresponding input stream.

![](/img/Javascript-reactive-programming/cycle_lifecycle.png)

The DOM and HTTP drivers are just the tip of the iceberg. There are plenty more drivers imaginable, such as the [history driver](https://github.com/cyclejs/history) for the browser's [History API](https://developer.mozilla.org/docs/Web/API/History_API), a [storage driver](https://github.com/cyclejs/storage) for interacting with [localStorage](https://developer.mozilla.org/docs/Web/API/Window/localStorage), [and more](https://github.com/cyclejs-community/awesome-cyclejs#drivers). Of course, you can also [write your own](http://cycle.js.org/drivers.html).

## Wrapping up

As we saw, the combination of observables and functional programming principles can greatly simplify working with asynchronicity such as often abundant in web applications, and that is still difficult to deal with in [the current crop of Javascript frameworks](https://vincenttunru.com/2016-javascript-framework-overview/). It's been getting more and more uptake as React developers slowly get familiar with a reactive programming style, and Angular developers set to have the full power of RxJS available in version 2. Cycle.js shows, however, that observables can be used far more extensively, for all that is asynchronous, in an elegant application architecture.

[![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/)._


Up-and-coming: Reactive programming in Javascript



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


One of the reasons I created [A Grip on Git](//agripongit.vincenttunru.com/) was that there were some things with which I wanted to play. One of those things was [Redux](http://redux.js.org/), a library that greatly simplifies state management in your Javascript applications. It helps you to be more explicit about possible changes in your application state by defining all possible state transformations as ([pure](https://en.wikipedia.org/wiki/Pure_function)) functions (referred to as _reducers_ in the Redux documentation).

This has many benefits for you as a developer. One such benefit is that it enables a very cool project called [Redux DevTools](https://github.com/gaearon/redux-devtools). DevTools allows you to undo and redo actions you performed earlier on demand, bringing a running app into the state it would have been in had those actions never happened.

![A showcase of Redux DevTools.](https://i.imgur.com/J4GeW0M.gif)

In A Grip on Git, I wanted to do something similar. As you scroll down the tutorial, Git commands are executed as appropriate to that point in the tutorial. When you scroll back up, however, the visualisation should transform back to the previous state, as if the later commands had never happened. To explain how this works, let's first look at reducers.

## How did reducers work, again?

Reducers are simple functions that take the current state and an action, and return the new state:

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

To keep your app maintainable, it is often advisable to split up your reducers to only concern themselves with parts of the state. For example, you can have a `gitCommands` reducer that can only manipulate `repository` part of the application state, and a `view` reducer that can only manipulate the `view` part of the state:

```js
import gitCommandReducer from 'gitCommandReducer.js';
import viewReducer from 'viewReducer.js';

(state, action) => {
  return {
    repository: gitCommandReducer(state.repository, action),
    view: viewReducer(state.view, action),
  };
}
```

Since this pattern is so common, Redux includes a utility called `combineReducers` with which you can remove the boilerplate. We won't be using that where we're going, though.

## Snapshotting

The reducers demonstrated above stand on equal footing. To enable undoing and redoing, however, we're going to create a reducer that _wraps_ the other reducers, applying to the application state as a whole. This `snapshotReducer` will be active in these three cases:

1. When an action is a Git command, it will keep track of it.
2. When an action is of type `VISIT_SECTION`, and that section hasn't been visited before, it will save a snapshot of the commands resulting in the current state.
2. When an action is of type `VISIT_SECTION`, and that section _has_ been visited before, it will restore the state the way it was when that section was first visited. It will do so by replaying all the actions kept track of in step 1, repeatedly applying the `gitCommandReducer` starting from an empty repository.

The code looks something like this:

```js
// Reducers
import gitCommandReducer from 'gitCommandReducer.js';

// Possible action types
import { GIT_COMMIT, GIT_PUSH } from 'gitCommandActions.js';
import { VISIT_SECTION } from 'viewActions.js';

const snapshotReducer = (state, action) => {
  // Case 1: keep track of Git commands
  if(
    action.type === GIT_COMMIT ||
    action.type === GIT_PUSH
    // etc.
  ){
    const history = state.history || [];
    return {
      ...state,
      ...{
        history: history.concat(action),
      },
    };
  }

  // Case 2: save a snapshot
  if(!state.snapshots[action.sectionName]){
    return {
      ...state,
      ...{
        snapshots: {
          ...state.snapshots,
          ...{
            [action.sectionName]: state.history,
          },
        },
      },
    };
  }

  // Case 3: restore the previously seen state
  if(state.snapshots[action.sectionName]){
    return {
      ...state,
      ...{
        // This is why they're called reducers:
        repository: state.snapshots[action.sectionName]
                    .reduce(gitCommandReducer, {}),
      },
    };
  }
}
```

Now all that's left to do is wrapping the state produced by our original reducers:

```js
import gitCommandReducer from 'gitCommandReducer.js';
import viewReducer from 'viewReducer.js';

(state, action) => {
  return {
    repository: gitCommandReducer(state.repository, action),
    view: viewReducer(state.view, action),
  };
}
```

…with the state as produced by our new `snapshotReducer`:

```js
import gitCommandReducer from 'gitCommandReducer.js';
import viewReducer from 'viewReducer.js';
import snapshotReducer from 'snapshotReducer.js';

(state, action) => {
  return snapshotReducer(
    {
      repository: gitCommandReducer(state.repository, action),
      view: viewReducer(state.view, action),
    },
    action
  );
}
```

## The bottom line

Redux's elegant uncoupling of state management has many benefits. By composing our reducers, we can implement undo/redo functionality _without needing to alter the original reducers_. Likewise, Redux DevTools work on any Redux app regardless of what its reducers do. By wrapping it around your app's reducers, it can keep track of all actions coming in, and replay them using your reducers when necessary.

This is just one of the many ways Redux can improve your life as a developer, so if you haven't tried it yet, I highly encourage you to do so.

[![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/)._
