Post-MVC part 7: Cycle.js


Last week we took a look at Reactive Programming and Observables. We saw the power that the Observables bring to the table, a very strong separation of concerns between components.

This week I want to take a look at Cycle.js which is a library which lets you create Components which take in observables as input and return observables as an output.

Post-MVC part 6: Reactive Programming


Last week I ended on a cliffhanger saying React is often criticized for not being truly reactive. So this week I want to define what Reactive Programming is all about.

Reactive Programming

To define Reactive Programming we must first look at the form of programming most of us are used to, in the reactive world they call it 'Passive Programming'. The passive and reactive come from the way two 'components' communicate with each other.

In Passive Programming the relationship between two components is that one component usually controls the other component. For example if we have a Car and an Engine component, the Car object triggers the Engine component. An example in code:

Using ui-router as a Component Router


In Angular 1.5 we got the Component, it is an improvement on our old pal the Directive. In fact a Component is just a Directive with some default settings, and a nicer API.

Here is a great blog post by Todd Motto which explains Components in dept, and compares them to ordinary directives.

A tale of two Components

Components have one other nice feature, they are closely aligned to the way Angular 2.0 will work. In fact if you squint your eyes you cannot really see the difference:

Post-MVC part 5: Redux


Last week we delved into Flux and saw the benefits of having a unidirectional architecture. We also learned that there were multiple Flux implementations, each implementing Flux in slightly different ways to improve upon it.

This week I want to take a look at Redux which takes Flux and improves it greatly making all sorts of cool things possible. Redux is the most popular Flux implementation at the moment.


Redux takes Flux and improves on it, so what are the differences between Flux and Redux?

A single source of Truth

Flux has the concept of Stores, which represent a group of domain entities and the operations that can be performed on them. For example a CarStore would contain all 'car' objects and have operations to add and remove cars.

Each domain entity has their own Store. This means that the 'state' of the application, whilst having a clear location, is still located in multiple objects. Redux argues against this approach, Redux has a single Store for every entity. In other words the entire state of the application is stored inside a single variable.

This sounds a bit like a mad idea but it actually has benefits.

Post-MVC part 4: Enter the Flux


Last week we discovered that Component based applications are trees. We saw that Components can only communicate one level up the tree and one level down. If a Component wants to communicate with his 'siblings' he will have to to that via his parent.

We also learned that the state of the application resides in the Components, but that it is not always apparent where the state should live.

The intercommunication between Components and the location of the state can make Component based applications complex. This week we are going look into a architecture called 'Flux' in order to see how this complexity can be tackled. 

Enter the Flux

React is a Component based View library from Facebook. It popularized the Component based approach and made it mainstream.

Facebook at some point discovered the weakness of traditional MVC and created a new way of managing state. They created Flux an architecture that uses a unidirectional data flow.