Post-MVC part 8: Conclusions


In this series we've learned about the benefits of a Component based architecture and we have seen how it differs from the traditional MVC architecture.

A Component based architecture is a Tree of Components in which each Component takes care of a part of the UI of an application. We saw that managing state for a Tree of Components can be difficult because the state lives in various locations.

We also saw that communication between Components can be difficult because a Component can only talk with his children or with his parents. Components that need to talks to their siblings or nephews require channels to be opened through their parents.

We learned about unidirectional data flows and about observables, two ways to reduce the complexity of a Component based architecture.

This week I want to share my personal opinions and experiences about Components, Redux, Cycle.js, Observables etc etc.

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.

Post-MVC part 3: Post-MVC Age


Last week we learned that the various MVC frameworks all share a the same abstraction called the Component, and that the Component is a tiny MVC application wrapped in one construct. More and more frameworks are using Components all the way down, this week we learn how an application which only uses Components works.

I call this the Post-MVC Age. 

Post-MVC Age

If we built our entire front-end applications with Components instead of using MVC how would that work? In this post I want to show you how to do just that. We will also discover some of the weaknesses of the Component model regarding state.

Post-MVC part 2: MVC and JavaScript


Last week we discussed what MVC is and how it was used to render application and websites from the server. But our application's user interfaces became too ambitious and our code became spaghetti. This week we will discuss MVC and JavaScript, and the birth of the Component.

MVC and JavaScript

Taking full control of the UI meant things had to be programmed on the browser side. Meaning that things had to be programmed in JavaScript.

This gave rise to the era of the browser based MVC controller frameworks. Backbone was the early pioneer showing us that we could straighten our jQuery Spaghetti. Angular and Ember improved upon Backbone by giving us automatic bindings, when the model changed the views were automatically updated.

Backbone, Ember, Angular are all MVC frameworks, which took the tried and true architectural pattern, and allowed us to make great applications.

And for a while everything was good.

Post-MVC part 1: We need to talk about MVC


In this series of blog posts I want to take a look past traditional MVC for the front-end. There have been lots of developments in architectures that do not look like MVC at all such as Flux and Reactive Programming.

The goal of this series is to show you how these other architectures came into being, the problems they try to solve, and how they relate to each other. This series is not an exhaustive tutorial on these new architectures instead it seeks to provide you information on a more conceptual level.

We need to talk about MVC

For a long time MVC has been our golden goose. It became our GOTO pattern for creating user interfaces. It has been been so ubiquitous that for a long time if someone create a new framework for handling User Interfaces, you would automatically assume that it is an MVC  framework.

But 'The times they are a changin'. MVC for the front-end seems to be dying of in favor of something "else". This is the first part of a  series of blog post trying to figure out what this "else" is.

But first we must define what MVC is.

The Case for BeanMapper


For a Spring Web developer, the situation is probably well known; you have an Entity, defined as a class that is persisted to some kind of persistence layer. The Entity must be partially exposed to the outside world and the Entity must be creatable and updatable.