Basic monads in Javascript

I'm going to explain some common monads that you can start using in your javascript today. Monads will help make your code easier to read, more maintainable and most importantly - safer.

Maybe

The Maybe monad is used for dealing with nullable data. Often we like to process data in javascript, like formatting, doing calculations, filtering and sorting. But often we need to make sure the data is there before doing anything. This is where Maybe can help.

I'm going to be using a small friendly helper library called Pratica for providing an implementation of the monads in this article.

Let's take a look at a snippet that can benefit from the Maybe monad.

const data = 'Hello my name is Jason'

if (data) {
  console.log(data.toUpperCase()) // HELLO MY NAME IS JASON
}

Now lets see how that can be refactored with a Maybe.

import { Maybe } from 'pratica'

Maybe('Hello my name is Jason')
  .map(data => data.toUpperCase())
  .cata({
    Just: data => console.log(data), // HELLO MY NAME IS JASON
    Nothing: () => console.log('No data available')
  })

See we don't need to check if the data exists, because Maybe will automatically not run any functions afterwards if the data is null. Avoiding error's like Uncaught TypeError: Cannot read property 'toUpperCase' of undefined

Now you might not see the advantage right away, but this isn't where Maybe shines. Let's look at another example with more steps.

// Step 1: Filter cool people
// Step 2: Find the first cool person
// Step 3: Log their uppercased name if there is one

const data = [
  { name: 'Jason', level: 7, cool: true },
  { name: 'Blanche', level: 8, cool: false }
]

if (data) {
  const coolPeople = data.filter(person => person.cool)
  if (coolPeople) {
    const firstCoolPerson = coolPeople[0]

    if (firstCoolPerson && firstCoolPerson.name) {
      console.log(firstCoolPerson.name.toUpperCase()) // JASON
    }
  }
}

Now let's see the Maybe alternative.

import { Maybe } from 'pratica'

Maybe(data)
  .map(people => people.filter(person => person.cool))
  .map(people => people[0])
  .map(person => person.name)
  .map(name => name.toUpperCase())
  .cata({
    Just: data => console.log(data), // JASON
    Nothing: () => console.log('No data available')
  })

If data was actually null or undefined, then none of the .map functions would run and the Nothing function would be executed in the cata.

But let's say we also wanted to return a default value if the data was null. Then we can use the .default() method.

import { Maybe } from 'pratica'

Maybe(null)
  .map(people => people.filter(person => person.cool))
  .map(people => people[0])
  .map(person => person.name)
  .map(name => name.toUpperCase())
  .default(() => 'No cool people yo')
  .cata({
    Just: data => console.log(data), // No cool people yo
    Nothing: () => console.log('No data available')
  })

Wow such clean, much flat.

Result

So we learned that the Maybe monad is good for dealing with nullable data, but what if we want to check the value of the data and do different things depending on the values.

Enter the Result monad (or sometimes called the Either monad).

Result is used for "branching" your logic. Let's take a look at an example without Result first.

const person = { name: 'Jason', level: 7, cool: true }

if (person.level === 7) {
  console.log('This person is level 7, ew')
} else {
  console.error('This person is some other level, but not 7')
}

Ok, now with Result.

import { Ok, Err } from 'pratica'

const person = { name: 'Jason', level: 7, cool: true }

const lvl = person.level === 7
  ? Ok('This person is level 7, ew')
  : Err('This person is some other level, but not 7')

lvl.cata({
  Ok: msg => console.log(msg), // This person is level 7, ew
  Err: err => console.log(err) // This person is some other level, but not 7
})

Humm, I don't see the point of this. What is Ok and Err? How is this better?

Let's do one more example before explaining it.

In this example, we'll have some data we need to validate before proceeding.

const data = {
  first: 'Jason',
  level: 85,
  cool: true,
  shirt: {
    size: 'm',
    color: 'blue',
    length: 90,
    logo: {
      color1: '#abc123',
      color2: '#somehexcolor'
    }
  }
}

if (data) {
  if (data.shirt) {
    if (data.shirt.logo) {
      if (data.shirt.logo.color1 !== 'black') {

        // Color1 is valid, now lets continue
        console.log(data.shirt.logo.color1)

      } else {
        console.error ('Color1 is black')
      }
    } else {
      console.error ('No logo')
    }
  } else {
    console.error ('No shirt')
  }
} else {
  console.error ('No data')
}

That looks a bit messy. Let's see how we can improve that with Result.

import { Ok, Err } from 'pratica'

const hasData = data => data
  ? Ok (data.shirt)
  : Err ('No data')

const hasShirt = shirt => shirt
  ? Ok (shirt.logo)
  : Err ('No shirt')

const hasLogo = logo => logo
  ? Ok (logo.color1)
  : Err ('No logo')

const isNotBlack = color => color !== 'black'
  ? Ok (color)
  : Err ('Color is black')

hasData (data2)
  .chain (hasShirt)
  .chain (hasLogo)
  .chain (isNotBlack)
  .cata ({
    Ok: color => console.log(color), // #abc123
    Err: msg => console.log(msg)
  })

Interesting, it's a lot flatter, but I still don't understand what's going on.

Ok, here's what's happening.

We start with the hasData function. That takes the initial data that needs to be validated and returns the next data that needs to be validated, but returns it wrapped inside the Result monad, more specifically, the Ok or the Err type. Both of those are what makes the Result monad, and those are how our application will branch the logic.

Why is there .chain() for every line?

Well each function is returning either an Ok or an Err data type. But every function is also expecting it's input to be just data, and not data wrapped inside of a monad. So calling chain on each function will unwrap the data from the monad so the function can read what's inside.

Why is this better?

Well, better is subjective, but in functional programming this is considered better because it pushes the IO (IO being the console logging statements) to the edges of the program. That means that there are more pure functions that can be unit tested and don't have IO mixed inside of them. Having IO inside of pure functions don't make them pure anymore, which means they would be harder to unit test and be a source of bugs. Console logging is not a big deal in javascript, but if the IO was making a network request, then this type of programming makes a big difference, because all logic/validation would be independent of IO and easier to test and maintain.

So those are 2 popular monads you can start using today.

This is my first article of dev.to so let me know what you think in the comments!

If you'd like to learn more about monads, check out these cool articles and libraries.

• Pratica
• Monads in pictures
• Fantasy Land
• Sanctuary JS
• Fistful of monads