React: The Gateway Drug to Functional Programming

Marc Cyr
3 min readJul 11, 2016

Just some random thoughts I’ve been having about Functional Programming and the impact of React on individual engineers (starting with myself).

tl;dr:

React opens the door to functional programming patterns in ways other things have not in the past for JavaScript engineers. The result is the ability for us to explore functional patterns more thoroughly as it feels more accessible.

Functional programming in JavaScript is like calculus. If you try to jump in immediately, it is confusing and disorienting. Yet, if you learn everything that comes before it (algebra, geometry, trigonometry, etc), then calculus becomes much more approachable and makes a lot more sense. In short, it becomes easier to grasp and as a result it becomes easier to use effectively.

In JavaScript, making the jump to using functional patterns is overwhelming and unapproachable when one has not yet learned the pieces leading up to it. You have to start with the basics of OOP before beginning the climb up the mountain to functional patterns.

Luckily (and I say this for many reasons), we now have React. React has solved many problems in UI engineering and at the same time has introduced many developers to functional patterns — without making it a difficult task. It is almost like being tricked into functional programming (in a good way).

With React components, the pattern is simple at its most pared-down: data in, UI out.

(data) -> ui 

Functional programming is primarily characterized by one very important concept: the absence of side effects. This has been described by many articles, books and posts that came long before this.

The reason I bring this up is because this is a primary focus of React: a class created in React should take data in and output UI. It should not have side effects.

React brings the very basic essence of functional programming to the table. It provides abstractions such as components which are basically (pure) functions and get you away from imperatively touching the DOM. source

The point is that React is all about writing composable idempotent functions. Which invokes multiple key tenets of functional programming: composability and pure functions.

This leaves us here:

  1. ReactJS is a gateway drug to functional programming because it uses and enforces core concepts of functional programming in its use for dealing with state changing over time in modern web applications.
  2. By exposing JavaScript engineers/developers to functional programming concepts, ReactJS is opening the door to deeper exploration of functional patterns.

The newly opened door to functional programming can take the modern JavaScript engineer various directions:

It can feel like falling down the rabbit hole in Wonderland, only to discover it goes deeper and deeper and leaves one’s head spinning.

Monads, applicatives, functors! WTF is all this?!?

It can also feel like following a dead-simple recipe (such as making simple syrup for a cocktail… 1 part water, 1 part clean/elegant code).

A couple great libraries the door may open for you are RamdaJS and FP-Lodash (which is the functional version of the much-loved Lodash library).

Another important thing that begins to open up, and become understandable, is RxJS. RxJS is a library that derives from Functional Reactive Programming. The simplest breakdown I can make of this is: programming using event streams.

Ben Lesh has said “RxJS is Lodash for async.” I think this is a pretty great summary of what RxJS can do.

The point is that this is another area of functional programming that presents itself after that door has been opened.

Other resources:

  1. Redux Observable
  2. RxJS
  3. Why Ramda?

--

--

Marc Cyr

Husband and father. Head of UI for Prisma Cloud at Palo Alto Networks running a large engineering team. Angel investor in Silicon Valley. https://20x.capital