
When React first burst onto the scene, its primary innovation was the Virtual DOM: instead of having to manually make sure the DOM is in sync with the actual application state, you'd just recreate a representation of the full DOM on every state change, and React would then update the actual DOM with exactly the changes needed to make it match. React components were simply a function of the application state, and the main benefit of that, as was the slogan at the time, is that it makes them _easy to reason about_. We were now able to create highly interactive client-side applications without introducing countless subtle bugs that were hard to catch.

Although that enabled way richer client-side applications than before, all that logic could only be executed once the code was downloaded and parsed by the user's browser, with nothing bug a blank page for the user to stare at. So we started doing Static Site Generation: do the first render of the virtual DOM at build time, and use that to send the user some HTML that can be shown while waiting for the client-side code to run. Of course, since that first render is done on the server side, you can't use client-side APIs in there, so make sure to keep in mind what environment the code you're writing might be running in. For example, you could set a state variable as a side-effect, and then wrap your code in a check for that variable.

One downside is that SSG happens at build-time, and thus only works for HTML that looks the same for every user. So we came up with tricks to customise the initial payload at runtime: Server-Side Rendering. Often implemented as separate APIs which only run on the server-side, and thus can access server-side APIs and secrets to fetch the relevant data for the user, and then pass those as props to your components. Of course, if that data is updated in the lifecycle of the client-side application, then that will have to make sure that the updated data is shown instead of the initial data passed as props.

With SSR we could now always send useful HTML while the user was waiting for the client-side code to have run, but we can't start sending that until we've collected _all_ the data a page needs, no matter how unimportant. Besides, it was bolted on top of React through proprietary APIs specifc to the different frameworks that implemented it. So we got server components in React itself, which can be rendered completely on the server, sent as soon as they're ready, and don't have to (virtually) be rendered again on the client-side, thus no longer delaying the client-side interactivity.

These server components look similar to traditional, now-known-as client components, can access async and server-side APIs, but they cannot access client-side APIs, nor state and effects. Client components will usually _also_ render on the server, so also make sure not to access client-side APIs in their first render. Also, you can have individual functions inside client components call server-side APIs if they're submit event handlers for forms, or wrapped in a "transition", and have `"use server"` at the top of the function body. Components are server components by default, but become client components if they have `"use client"` at the top. Well, or if one of their parent components has that, so make sure you to check where your component gets used before accessing server- or client-side APIs, or avoid both altogether.

## Is React too complex?

Well… In theory, the changes have been strictly additive: it is still perfectly possible to build an app that is fully rendered on the client side, and the view is mostly a function of state. What _has_ changed, is our demands: we want the first-load performance of traditional, fully server-rendered websites where possible, combined with the reliable highly-interactive client-side experiences where needed. It's possible that exercising such granular control just comes with inherent complexity, and React is the best we can do in terms of managing that.

But maybe not?


React's main benefit used to be that it was easy to reason about. Is it still though?

React was easy to reason about


_Create React App_ 2.1.0 just arrived [with TypeScript support](https://github.com/facebook/create-react-app/releases/tag/v2.1.0)! While [Will Monk](https://twitter.com/willmonk)'s fork [_create-react-app-typescript_](https://github.com/wmonk/create-react-app-typescript/) has served us well, being able to use the official version has a number of advantages. Most importantly: it is supported by the full weight of the Create React App team, and will therefore stay closely aligned with React proper and will always have up-to-date documentation. Furthermore, you are able to use everything that is supported by Create React App, like [Sass](https://sass-lang.com/).

The implementation also deviates a bit from create-react-app-typescript's. Most importantly, TypeScript is only used for type checking, whereas transpilation is done by [Babel](https://babeljs.io/). The disadvantage of this is that you are behest to the caveats of [Babel's TypeScript support](https://blogs.msdn.microsoft.com/typescript/2018/08/27/typescript-and-babel-7/), most notably the lack of namespaces and having to use the `x as Foo` type casting syntax. In practice, however, it is unlikely that these caveats will affect a React app, and the upside is that you are now able to tap into Babel's extensive ecosystem.

So great: we can now use TypeScript for new apps created with Create React App. However, many of us already have apps written using create-react-app-typescript. How much work is it to port those to Create React App proper?

As it turns out: not that much. Let's get to it.

## Step 1: remove react-scripts-ts, add react-scripts

Create React App is a command line application that generates a basic React application for you, but instead of adding all commonly used dependencies directly, it adds a single dependency that bundles them and is maintained by the CRA team itself: `react-scripts`. Likewise, create-react-app-typescript has its own fork of this: `react-script-ts.` Thus, the main thing to do when migrating, is switching over this dependency:

```bash
$ npm uninstall react-scripts-ts
$ npm install react-scripts
```

Then, we have to make sure that the new scripts are the ones that are actually called when we run `npm start`, `npm test`, etc. Thus, in your `package.json`, replace:

```json
  "scripts": {
    "watch": "react-scripts-ts start",
    "build": "react-scripts-ts build",
    "test": "react-scripts-ts test --env=jsdom",
    "eject": "react-scripts-ts eject",
```

with

```json
  "scripts": {
    "watch": "react-scripts start",
    "build": "react-scripts build",
    "test": "react-scripts test",
    "eject": "react-scripts eject",
```

## Step 2: Activate TypeScript support

Although CRA now supports TypeScript, you do have to [explicitly enable it](https://facebook.github.io/create-react-app/docs/adding-typescript). This can be done by simply installing a few packages:

```bash
$ npm install --save typescript @types/node @types/react @types/react-dom @types/jest
```

## Step 3: Clean up the remnants of create-react-app-typescript

create-react-app-typescript did a few things differently from how Create React App proper does it, and therefore added a few files that now are no longer needed or are now named differently. Don't worry, though; we will recreate the relevant and properly named files in a moment.

The outdated files are `tsconfig.json`, `tsconfig.prod.json`, `tsconfig.test.json` and `images.d.ts`. To remove them with a single command:

```bash
$ rm tsconfig.json tsconfig.prod.json tsconfig.test.json images.d.ts
```

(Note that, apart from [a few options](https://github.com/facebook/create-react-app/blob/87e3d4fd1080d290f675d0461e3d3656752628ab/packages/react-scripts/scripts/utils/verifyTypeScriptSetup.js#L105-L129), you will still be able to customise `tsconfig.json` to your likings.)

## Step 4: Run it!

You should now be set! If you now run your app for the first time, Create React App will create relevant files, such as a new `tsconfig.json`, for you:

```bash
$ npm start
```

If everything went well, you should now have a running app. Not so bad, was it?

Depending on your setup, though, there might be a few additional problems you might run into.

## Troubleshooting

I will try to keep the following list up-to-date with problems that people run into, and how to solve them. Ran into any yourself that was not documented here? Let me know [on Twitter](https://twitter.com/VincentTunru) or <a href="mailto:blog@VincentTunru.com" title="Send me an email">by email</a>.

### Absolute imports

create-react-app-typescript allowed specifying your imports relative to your root directory. In other words, no matter which file you were editing, you could do

```javascript
// In src/components/Bar/Bar.tsx
import { Foo } from 'src/components/Foo/Foo.tsx';
```

This is useful because it allows you to move your files around as you please, but also makes it less transparent where your imports are coming from.

Create React App does not support this. To fix this, make your imports relative:

```javascript
// In src/components/Bar/Bar.tsx
import { Foo } from '../Foo/Foo.tsx';
```

### Importing CSS files from node_modules

In create-react-app-typescript, you could directly import CSS files that were located in `node_modules` from within a React component:

```javascript
// In Foo.tsx
import 'node_modules/bulma/css/bulma.min.css';
```

With Create React App, you can still import from `node_modules` but, like above, can not rely on absolute imports. However, you _can_ import directly from subfolders in `node_modules:`

```javascript
// In Foo.tsx
import 'bulma/css/bulma.min.css';
```

### Value not found, property does not exist on type, etc.

If you were using modern JavaScript API's in your code, you have to tell TypeScript to include the relevant type definitions. To do so, add the `lib` property to the `compilerOptions` in your `tsconfig.json`, and add the type definitions you use, e.g.:

```json
    "lib": ["esnext", "dom"]
```

Also make sure that, if you want to support older browsers like Internet Explorer 11, you [include the relevant polyfills](https://github.com/facebook/create-react-app/blob/master/packages/react-app-polyfill/README.md).

### Parsing error: Unexpected token

This can be the result of an ESLint configuration that does not incorporate Create React App's default configuration. If you have an `.eslintrc` file (possibly with an extension), add:

```json
  "extends": [
    "react-app",
    "react-app/jest"
  ]
```

(or add those two values to an existing `extends` property if present.)

If you don't have an `.eslintrc` file, add the following to your `package.json`:

```json
  "eslintConfig": {
    "extends": [
      "react-app",
      "react-app/jest"
    ]
  },
```

(or add this to an existing `eslintConfig` property if present.)

For more info, see https://github.com/facebook/create-react-app/issues/9791.

Thanks to Justus R for getting in touch to share this!

### Other type checking errors

Create React App enables strict mode for TypeScript. This can help you catch many errors, and I would suggest you to try to fix the errors you encounter. That said, create-react-app-typescript only enabled a subset of the strict type checking options, and moving to a stricter mode now might be too much of a hassle. To loosen these restrictions, you can try to manually disable the checks you are violating in the `compilerOptions` in your `tsconfig.json`, e.g.:

```json
    "alwaysStrict": false,
    "strictFunctionTypes": false,
    "strictPropertyInitialization": false,
```

### Allocation failed - JavaScript heap out of memory

If you use Yarn, adding or removing dependencies might start to fail. This is likely due to Yarn not being able to process the untold masses of dependencies. One factor that can strongly bloat your number of dependencies is if you are using [Storybook](https://storybook.js.org/) 3, because it includes other versions of Webpack, Babel, etc. than Create React App 2 is using. Luckily, Storybook _also_ just released a new version that should be compatible with the package versions used by Create React App, so following [the Storybook v4 upgrade instructions](https://medium.com/storybookjs/migrating-to-storybook-4-c65b19a03d2c) should solve this issue. Be sure to also read the paragraph below to make Storybook work.

### Storybook

Storybook uses its own Webpack configuration to load your stories. It uses `babel-loader` and, if you followed [the official docs on using TypeScript with Storybook](https://storybook.js.org/configurations/typescript-config/), `awesome-typescript-loader` to do so, which are not included with CRA. Thus, you will have to install those manually:

```bash
$ npm install babel-loader awesome-typescript-loader
```

Additionally, while Create React App uses Babel to parse JSX, Storybook expects TypeScript to do so. Thus, create a Storybook-specific TypeScript configuration in `.storybook/tsconfig.json` that extends the one you already have with that setting, as follows:

```json
{
  "extends": "../tsconfig",
  "compilerOptions": {
    "jsx": "react",
  },
}
```

Then, in `.storybook/webpack.config.js`, tell `awesome-typescript-loader` to use that configuration file:

```javascript
    loader: require.resolve('awesome-typescript-loader'),
    options: { configFileName: path.resolve(__dirname, './tsconfig.json') }
```

You should now be good to go!

## Thanks

The main driver behind adding TypeScript support to Create React App was [Bruno Lemos](https://twitter.com/brunolemos), who worked very hard on [his pull request](https://github.com/facebook/create-react-app/pull/4837). Of course, he could not have done that without the support of the Create React App team, and in particular [Joe Haddad](https://twitter.com/timer150), who spent a lot of time reviewing the pull request - and also reviewed this blog post. And of course, we should be grateful to [Will Monk](https://twitter.com/willmonk), who maintained ~~[(and is still maintaining)](https://github.com/wmonk/create-react-app-typescript/commit/ef987c15acad6468a35ddb0a24ba22add819207e)~~ his excellent fork of create-react-app that allowed us to use TypeScript when it was not officially supported yet.

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


Migrating from create-react-app-typescript to mainline Create React App was surpisingly easy. Here's how to do it.

Migrating from create-react-app-typescript to Create React App



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