React: Controlling state to accelerate development

I first started looking at the React JavaScript library from Facebook in early 2014. I had previously worked on sites using MVC frameworks like Angular and Backbone and at first it was hard to see what problem React was trying to solve. The other frameworks had an API for templating and even HTTP calls, but React could only render HTML in the browser. When I dug into the design it soon became clear what the goal of React is. It controls the amount of state required to render UI elements and it allows developers to create components with a single responsibility that can be safely composed into a whole system. The following is a high level overview of how React achieves this.

How React controls state

The core principle of React is to control and encapsulate the state of the user interface. React components do this by exposing two objects, Props and State.

Props

Props are supplied by a parent component to the children it creates. The props object is set at the time the component is created and it never changes, therefore it is immutable. This enforces one-way data binding so that an element, for example an input control on a form, can be populated with a value held in the props object.

However, when the user changes the value in the input field it will not change the value from the props object that it is bound to. The advantage of this is that values in the props object can be safely used anywhere in the UI and we know that they will not change the state of the application. The only place they can be changed is in the component that owns the original state. Components that only use props are stateless which means their behaviour is derived from the inputs given to them.

State

State is an object of a component and it is private to the component. The state can only be shared with child components by passing the values as props. The children can not change the state, only render it. If a child does need to mutate the state of the parent, the parent component provides a callback function in the props object. This allows the parent to decide how and when it will mutate the state. This builds upon the one-way data binding model into a one way data flow model for the application. With React, the user interface is composed of mainly stateless components with some stateful parent components controlling how state changes. With this model, the data flows down the tree of components and messages flow back up the tree in the form of callback functions to trigger state changes.

How React applies functional programming

The design of React is heavily influenced by principles common to functional programming. In fact the first prototype of React was created in OCaml. Stateless components are essentially pure functions and the encapsulation of the mutation of state is a core tenant of most functional programming languages. The building of a user interface by composing smaller components together in React is the same as function composition in functional programming. I am pleased to see the principles of functional programming forming the basis for a very popular library, as I believe that they lead to safer software that is quicker to develop.

Conclusion

React brought the principles of functional programming to the JavaScript ecosystem. It also captures a view that I have that software should be developed so that state is never changed in more than one location. I have seen many applications become brittle and impossible to extend because state is being changed in a number of places. The change becomes difficult because all the points of mutation must be found and checked to see that they still work with the change being made. A single point of mutation makes this problem go away.

React has now reached a point of maturity where the API has stabilized as have the supporting tools like Redux and react-devtools. It is the tool I now choose to build new web applications. It forces me to think up front about all the components I need for the user interface and which ones will hold state and which ones can be stateless. For more information look at Pete Hunt’s great post or try React using the new create react app tool.

F# in Finance conference

On Monday 25th November I attended the F# in Finance conference at the Microsoft offices in London. I was drawn to this single day conference as I have been learning about functional programming for some time now. I am also interested in the finance sector as it seems paradoxical to me. On the one hand it appears to have ageing IT systems and an ardent use of Excel.  This seems like a bizarre way to run any business let alone a financial institution. On the other hand they can be at the forefront of innovation in software development. Indeed it is arguably the biggest commercial adopter of functional programming so far. So, I was keen to hear how this industry was changing and to learn if there were any lessons I could use in my own programming.

The day consisted of 10 talks, an ambitious goal for a single day. The most interesting theme that I picked up on was how productive many of the speakers felt when writing F# compared to C#. Jon Harrop and Phil Trelford both talked about how modelling complex domains was vastly simpler in a functional language than in an object oriented one. Phil explained how the energy trading system he maintains has a domain model which is just a single, two hundred line file. If this were to be implemented in an object oriented language the model would span hundreds of classes.

From the discussion about domain modelling it appears that functional languages are better at separating the data from the behaviour. This is still abstract in my mind so I have much to learn. What is more concrete for me are the language features that help productivity. When asked in a panel session, the speakers said that a lack of null values, immutability and the built in actor model are the main benefits when using F#. A lack of null values and immutability seem like an obvious gain. Null reference errors are a very common error in most systems. Mutated state is also a source of pernicious bugs. A rogue branch of code can create havoc to a well tested system if it alters some piece of state. The actor model is a higher level construct also aimed at limiting state changes in a system and in F# it is called the MailboxProcessor.

F# in Finance was a fantastic day of very focused presentations from some superb presenters. Functional programming is a clear fit for the finance sector where the domain can often be modelled in algebraic terms. Given that this is a sector where any competitive edge means vast profits I am sure the uptake of functional programming will only increase. It is good to see F# and, consequently, the CLR gaining a foothold. Thanks to the presenters I now have a clearer understanding of the advantages of functional programming and will be investigating further to see how I can improve my programming skills.

Functional JavaScript book review

I was very excited to receive my copy of Functional JavaScript by Michael Fogus as I am interested in, and have views on, both Functional programming and JavaScript. My view  of the functional programming community is that it is full of very clever people who are focused on creating software which is robust and malleable. This is probably because the concepts behind functional programming are hard to understand. It is also because it has a closer relationship to various branches of mathematics. My opinion of JavaScript is that it is the most ubiquitous programming language we have ever known. It is a language with some good features, but it has to be handled with care. The need for care is even greater when using it to program the DOM as this is a very complex API.

The use of functional programming in JavaScript is not a new idea, indeed it has many influences from Lisp and Scheme. But it is very good to see someone write a book exploring the topic. The style of the book is very conversational and each chapter moves up through the complex layers of functional programming.

At the beginning the focus is on higher order functions (functions taking in other functions as parameters) all the way to flow based programming and a brief overview of monadic programming. This structure demonstrates very well how functions can be composed together to create bigger programs. Functions written in each chapter re-appear in later ones to be part of a bigger whole.

I have read this book once and I am working my way through it again. It is rich with ideas for any JavaScript programmer.  The concepts of functional programming certainly stretched my imperative programmers mind. Stretched as it was, I enjoyed seeing Michael Fogus take an imperative process and re-implement it as a series of functions composed together. Functional JavaScript is a very enjoyable read and I would recommend you pick up a copy.