Functional Programming in JavaScript, Part 3: Introduction to Functors and Monads

This is part 3 in a series on Functional Programming in javascript

• Part 1: The Unit
• Part 2: The Monoid
• Part 4: The art of chaining different monads

After discovering the Unit and the Monoid, it's time to talk about Functors and Monads. I know, those words can be frightening. Their definitions are frightening, too:

Functor

A morphism from a source category to a target category which maps objects to objects and arrows to arrows, in such a way as to preserve domains and codomains (of the arrows) as well as composition and identities.

Monad

How is that supposed to be helpful? Let's forget those awful definitions and start with an example of problem the functor and monad resolve.

Checking Input Properties

Let's say I want to increment a number.

const increment = v => v + 1;
const a = 5;
increment(a); // 6

Simple, right? But then someone calls the increment function with an incorrect argument:

increment("5"); // '51'
// or like this
increment({ v: 5 }); // "[object Object]1"

So to handle this case, I need to add a type check to the function:

const increment = v => {
  if (typeof v !== "number") {
    return NaN; // NaN fit our purpose here, we received not a number, so we return just that
  }

  return v + 1;
};

increment("5"); // NaN
increment({ v: 5 }); // NaN

Good. Now, let's say that I need another function to double a number. Again, to be safe I need to repeat the same type check:

const double = v => {
  if (typeof v !== "number") {
    return NaN;
  }

  return v * 2;
};

In fact each time I manipulate a value, I should do some verifications:

• Is it the right type?
• Is it here?
• Was there an error?

And sometimes, the value is not even readily available, it comes in a callback, or not, maybe we will get an error.

Echanging The Function And Value Roles

What if instead of passing the value to the functions, we passed the functions to the value? Or rather to a placeholder for the value.

I mean, a value already knows some important things about the functions that will be called with it:

• If I am null, there is no need to execute the function.
• If I am not of the correct type, I should skip all functions passed to me.
• If I am an error, I should not execute this function, but I should execute this other one instead.
• If I am asynchronous, I should call this function once I arrive

In short, the value knows best what to do with the function.

This is the basic idea behind a pattern called Functor: a placeholder for a value, so that you pass the function to the value, and not the other way around. We are in functional programming after all: we want to manipulate functions, not values.

Let's write a placeholder for a number value: a NumberBox.

const NumberBox = number => ({
  applyFunction: fn => NumberBox(fn(number)),
  value: number,
});

NumberBox(5)
  .applyFunction(v => v * 2)
  .applyFunction(v => v + 1).value; // 11

For now, this code still suffers from the same problem on non-number arguments. So let's enhance the placeholder to check that it holds a numeric value before applying the function.

const NumberBox = number => ({
  applyFunction: fn => {
    if (typeof number !== "number") {
      return NumberBox(NaN);
    }
    return NumberBox(fn(number));
  },
  value: number,
});

NumberBox(5)
  .applyFunction(v => v * 2)
  .applyFunction(v => v + 1).value; // 11
NumberBox({ v: 5 })
  .applyFunction(v => v * 2)
  .applyFunction(v => v + 1).value; // NaN

This applyFunction method looks a lot like another function that we often use, doesn't it?

[1, 2, 3].map(v => v + 1);

That's right, Array.map() works the same: it takes values from an array instead of a box, but it applies the function all the same.

From now on let's rename applyFunction to map, as we map a function over a value.

const NumberBox = number => ({
  map: fn => {
    if (typeof number !== "number") {
      return NumberBox(NaN);
    }
    return NumberBox(fn(number));
  },
  value: number,
});

And, just like that, I have created a functor, which is a value placeholder offering a map function to execute functions on it.

So to recapitulate, I have a box that holds a value and can apply a function to it thanks to a map method. This allows adding custom logic to the function application. This way I manipulate a function, not a value. And with this pattern, I can do a lot more.

Using The Functor Pattern For Type Checking

Let's generalize the NumberBox function to handle any type checking, not just numbers. I'll create a TypeBox function, that generates a functor based on a test (or predicate, to use a more exact word):

const TypeBox = (predicate, defaultValue) => {
  const TypePredicate = value => ({
    map: fn =>
      predicate(value) ? TypePredicate(fn(value)) : TypePredicate(defaultValue),
    value,
  });
  return TypePredicate;
};

So now I can recreate the NumberBox by passing a number check as predicate, and NaN as default value:

const NumberBox = TypeBox(value => typeof value === "number", NaN);
NumberBox(5)
  .map(v => v * 2)
  .map(v => v + 1).value; // 11
NumberBox({ v: 5 })
  .map(v => v * 2)
  .map(v => v + 1).value; // NaN

I can also create a StringBox, a functor for strings:

const StringBox = TypeBox(value => typeof value === "string", null);
StringBox("world")
  .map(v => "Hello " + v)
  .map(v => "**" + v + "**").value; // '**Hello, world**'
StringBox({ v: 5 })
  .map(v => "Hello " + v)
  .map(v => "**" + v + "**").value; // null

And you can imagine how this applies to all kinds of type checks.

const double = v => v * 2;
const increment = v => v + 1;
NumberBox(5)
  .map(double)
  .map(increment).value; // 11
// will have the same result as :
NumberBox(5).map(v => increment(double(v))).value; // 11

NumberBox(5).map(v => v) == NumberBox(5)

Maybe Another Example

Sometimes, making a function robust isn't about checking the input type, it's about checking that the input exists. Like when a function accesses a property:

const street = user.address.street;

To handle the case where user or user.address are not set, I need to add existence checks:

const street = user && user.address && user.address.street;

I can use the functor pattern to handle such cases. The idea is to create a placeholder to hold sometimes a value, and sometimes nothing. Let's call this functor Maybe.

const isNothing = value => value === null || typeof value === "undefined";

const Maybe = value => ({
  map: fn => (isNothing(value) ? Maybe(null) : Maybe(fn(value))),
  value,
});

Now it's safe to call properties on a non-object:

const user = {
  name: "Holmes",
  address: { street: "Baker Street", number: "221B" },
};
Maybe(user)
  .map(u => u.address)
  .map(a => a.street).value; // 'Baker Street'
const homelessUser = { name: "The Tramp" };
Maybe(homelessUser)
  .map(u => u.address)
  .map(a => a.street).value; // null

Tip: Calling the value property at the end isn't very natural in functional programming. I can augment the Maybe functor with a getter that accepts a default value as argument:

const isNothing = value => value === null || typeof value === 'undefined';

const Maybe = value => ({
    map: fn => isNothing(value) ? Maybe(null) : Maybe(fn(value)),
    getOrElse = defaultValue => isNothing(value) ? defaultValue : value,
});

As for accessing object properties, it can get even better using a get helper:

const get = key => value => value[key];

const getStreet = user =>
  Maybe(user)
    .map(get("address"))
    .map(get("street"))
    .getOrElse("unknown address");

getStreet({
  name: "Holmes",
  firstname: "Sherlock",
  address: {
    street: "Baker Street",
    number: "221B",
  },
}); // 'Baker Street'

getStreet({
  name: "Moriarty",
}); // 'unknown address'

getStreet(); // 'unknown address'

Either Right or Wrong

What about error handling? If the function mapped on a functor throws an error, the functor should be able to handle it.

For instance, let's consider the code required to validate a user email. To be precise, I want to validate an email address only if it is given, otherwise, I ignore it and return null.

const validateEmail = value => {
  if (!value.match(/\S+@\S+\.\S+/)) {
    throw new Error("The given email is invalid");
  }
  return value;
};

validateEmail("foo@example.com"); // 'foo@example.com'
validateEmail("foo@example"); // throw Error('The given email is invalid')

I'm not fond of that throw, because it interrupts the execution flow. What I'd like is a validateEmail function that doesn't throw an error, but may return either a value or an error. How to do this with functors?

I need to return a different functor based on a try/catch: either a functor that allows me to continue to map, or a functor that would not change its value anymore (if it's an error). I'll call these two functors Left and Right. The validateEmail function would look like the following:

const validateEmail = value => {
  if (!value.match(/\S+@\S+\.\S+/)) {
    return Left(new Error("The given email is invalid"));
  }
  return Right(value);
};

The Left functor should never change its value anymore, whatever function is passed to its map:

const Left = value => ({
  map: fn => Left(value),
  value,
});

Left(5).map(v => v * 2).value; // 5

As for the Right functor, it simply applies a function to its value, transparently. You could call it the Identify functor, too.

const Right = value => ({
  map: fn => Right(fn(value)),
  value,
});

Right(5).map(v => v * 2).value; // 10

And now I can chain map calls on my email value:

validateEmail("foo@example.com") // valid email, return Right functor
  .map(v => "Email: " + v).value; // 'Email: foo@example.com'
validateEmail("foo@example") // invalid email, return Left functor
  .map(v => "Email: " + v).value; // Error('The given email is invalid')

The Left and Right functors form what we call an Either.

Catching Errors

The validateEmail returns either a result or an error, but doesn't allow me to do something specific in case of an error. For instance, I may want to catch the Error and log its message property.

I'll add a catch() function to both the Left and Right functors to allow me to do just that:

// on a Right, catch() should do nothing
const Right = value => ({
  map: fn => Right(fn(value)),
  catch: () => Right(value),
  value,
});
// catch is ignored on a right
Right(5).catch(error => error.message).value; // 5

// on a Left, catch() should apply the function, and return a Right to allow further mapping
const Left = value => ({
  map: fn => Left(value),
  catch: fn => Right(fn(value)),
  value,
});
Left(new Error("boom")).catch(error => error.message).value; // 'boom'

For better reusability, I combine these Left and Right functors into a generic tryCatch function:

const tryCatch = fn => value => {
  try {
    return Right(fn(value)); // everything went fine we go right
  } catch (error) {
    return Left(error); // oops there was an error let's go left.
  }
};

And now, I can use this new tryCatch function to decorate the initial implementation of validateEmail, and get either a Left or a Right functor in return.

const validateEmail = tryCatch(value => {
  if (!value.match(/\S+@\S+\.\S+/)) {
    throw new Error("The given email is invalid");
  }
  return value;
});

validateMail("foo@example.com")
  .map(v => "Email: " + v)
  .catch(get("message")).value; // 'Email: foo@example.com'
validateMail("foo@example")
  .map(v => "Email: " + v)
  .catch(get("message")).value; // 'The given email is invalid'

Combining Functors

Now, let's try to validate not an email string, but a user object that maybe has an email. I do not need to validate the email if the user has no email property.

Let's use Maybe and combine it with Either:

const validateUser = user =>
  Maybe(user)
    .map(get("email"))
    .map(v => validateMail(v).catch(get("message")));

validateUser({
  firstName: "John",
  email: "foo@example.com",
}); // Maybe(Right('foo@example.com'))

validateUser({
  firstName: "John",
  email: "foo@example",
}); // Maybe(Left('The given email is invalid'))

validateUser({
  firstName: "John",
}); // Maybe(null)

I always get a Maybe, but its value is either a Left or a Right functor, or even a null value. So in order to get the value, I have to test Maybe value to know what to do with it.

const validateUserValue = user => {
  const result = validateUser(user).value;
  if (value === null || typeof value === "undefined") {
    return null;
  }
  return result.value;
};

This is bad: all the code I worked so hard to remove is coming back for revenge. You can imagine that it gets worse if I try to combine more functors, ending up with .value.value.value.value...

How can I handle this crisis?

Chain To The Rescue

I need a method allowing me to extract a value of a functor, even though this value is wrapped inside another functor.

I need a flatten method that removes the inner functor, keeping only its value.

const Maybe = value => ({
    // we could return the value, but then we would sometimes switch functor type.
    // This way Maybe.flatten will always return a Maybe
    flatten: () => isNothing(value) ? Maybe(null) : Maybe(value.value),
    ...,
});

const validateUser = user => Maybe(user)
    .map(get('email'))
    .map(v =>  validateMail(v)
        .catch(get('message'))
    )
    .flatten()
    // since now I will always have a simple Maybe, I can use getOrElse to get the value
    .getOrElse('The user has no mail');

validateUser({
    firstName: 'John',
    email: 'foo@example.com',
}); // 'foo@example.com'

validateUser({
    firstName: 'John',
    email: 'foo@example',
}); // 'The given email is invalid'

validateUser({
    firstName: 'John',
}); // 'The user has no mail'

So now I can call .getOrElse and get the value directly. But that's still not ideal. You see, in functional programming, you often need to map and then flatten, or to flatMap for short. But the term "flatMap" describes what the procedure does, not what it is used for. This operation is used to chain functors, so let's call it that: chain.

const Maybe = value => ({
    flatten: () => isNothing(value) ? Maybe(null) : Maybe(value.value),
    // using the named function form instead of the fat arrow function
    // because I need access to this
    chain(fn) {
        return this.map(fn).flatten();
    },
    ...,
});

const validateUser = user => Maybe(user)
    .map(get('email'))
    .chain(v =>  validateMail(v)
        .catch(get('message'))
    )
    .getOrElse('The user has no mail');

validateUser({
    firstName: 'John',
    email: 'foo@example.com',
}); // 'foo@example.com'

validateUser({
    firstName: 'John',
    email: 'foo@example',
}); // 'The given email is invalid'

validateUser({
    firstName: 'John',
}).value; // 'The user has no mail'

Note that the two names are used in functional programming, so flatMap == chain.

Here Comes The Monad

By the way, a functor that can flatten itself with a chain method is called a Monad. So Maybe is a monad. Not so scary, right?

Monad(x).chain(f) === f(x);
// f being a function returning a monad

Monad(x).chain(Monad) === Monad(x);

monad.chain(f).chain(g) == monad.chain(x => f(x).chain(g));
// f and g being functions returning a monad

`Chain` must be associative: Using `.chain(f).chain(g)`, is the same as using `.chain(v => f(v).chain(g))`.

This ensures that we can `chain` function that uses `chain` themselves.

Conclusion

You can play with the code of this tutorial in the CodeSandbox below. It uses a slightly modified example: try to understand why it's better than what was explained earlier.

I hope I have demystified functors and monads, and shown how they can be useful. Next time, I will see how we can use monad to handle side effect in a functional way.