Functional Reactive Programming with Elm: An Introduction

Elm is a functional programming language that has been attracting quite a bit of interest lately. This article explores what it is and why should you care.

Elm's current main focus is making front-end development simpler and more robust. Elm compiles to JavaScript so it can be used for building applications for any modern browser.

Elm is statically typed language with type inference. Type inference means that we don't need to declare all the types ourselves, we can let the compiler infer many of the types for us. For example by writing one = 1, the compiler knows that one is an integer.

Elm is an almost pure functional programming language. Elm builds on top of many functional pattern like pure views, referential transparency, immutable data and controlled side effects. It is closely related to other ML languages like Haskell and Ocaml.

Elm is reactive. Everything in Elm flows through signals. A signal in Elm carries messages over time. For example clicking on a button would send a message over a signal.

You can think of signals to be similar to events in JavaScript, but unlike events, signals are first class citizens in Elm that can be passed around, transformed, filtered and combined.

Elm Syntax

Elm syntax resembles Haskell, as both are ML family languages.

greeting : String -> String
greeting name =
  "Hello" ++ name

This is a function that takes a String and returns another String.

Why Use Elm?

To understand why should you care about Elm, let's talk about some front-end programming trends in the last couple of years:

Describe State Instead of Transforming the DOM

Not long ago we were building applications by mutating the DOM manually (e.g. using jQuery). As our application grows we introduce more states. Having to code the transformations between all of them exponentially grows the complexity of our application making it harder to maintain.

Instead of doing this, libraries like React have popularised the notion of focusing on describing a particular DOM state and then let the library handle the DOM transformations for us. We only focus on describing the discreet DOM states and not how we get there.

This leads to substantially less code to write and maintain.

Events and Data Transformation

When it comes to application state, the common thing to do was to mutate the state ourselves e.g. adding comments to an array.

Instead of doing this we can only describe how the application state needs to change based on events, and let something else apply those transformations for us. In JavaScript, Redux has made popular this way of building applications.

The benefit of doing this is that we can write 'pure' functions to describe these transformations. These functions are easier to understand and test. An added benefit is that we can control where our application state is changed, thus making our applications more maintainable.

Another benefit is that our views don't need to know how to mutate state, they only need to know what events to dispatch.

Unidirectional Data Flow

Another interesting trend is having all our application events flow in a unidirectional way. Instead of allowing any component talk to any other component, we send message through a central message pipeline. This centralized pipeline applies the transformations we want and broadcasts the changes to all the parts of our application. Flux is an example of this.

By doing this we gain more visibility of all interactions that happen in our application.

Immutable Data

Mutable data makes it very hard to restrict where it can be changed, as any component with access to it could add or remove something. This leads to unpredictability, as state could change anywhere.

By using immutable data we can avoid this, by tightly controlling where application state is changed. Combining immutable data with functions that describe the transformations gives us a very robust workflow, and immutable data helps us enforce the unidirectional flow by not letting us change state in unexpected places.

Centralized State

Another trend in front-end development is the use of a centralized 'atom' for keeping all state. Meaning that we put all state in one big tree instead of having it scattered across components.

In a typical application we usually have global application state (e.g. a collection of users) and component specific state (e.g. the visibility state of a particular component). It is controversial whether storing both kinds of state in one place is beneficial or not. But at least keeping all application state in one place has a big benefit, which is providing a consistent state across all components in our application.

Pure Components

Yet another trend is the use of pure components. What this means is that given the same inputs a component will always render the same output. There are no side effects happening inside these components.

This makes understanding and testing our components far easier than before, as they are more predictable.

Back to Elm

These are all great patterns that make an application more robust, predictable, and maintainable. However to use them correctly in JavaScript we need to be diligent to avoid doing some things in the wrong places (e.g. mutating state inside a component).

Continue reading %Functional Reactive Programming with Elm: An Introduction%

by Sebastian Porto via SitePoint