Forem: Devin Holloway

Functional Type Safety in Javascript with Maybe

Devin Holloway — Sat, 13 Jul 2019 17:38:26 +0000

In programming languages (more so functional programming languages) and type theory, an option type or maybe type is a polymorphic type that represents encapsulation of an optional value; e.g., it is used as the return type of functions which may or may not return a meaningful value when they are applied. It consists of a constructor which either is empty (often named None or Nothing), or which encapsulates the original data type A (often written Just A or Some A).
-- Wikipedia

Let's talk about what this means, why it's useful, and how to utilize the concept in Javascript.

Javascript is an untyped language, which makes it very flexible, and in some cases, very powerful. But with that power comes great responsibility. Take for instance, a function designed to operate on a string:

const capitalize = a => a.charAt(0).toUpperCase() + a.slice(1)

capitalize('javascript') //=> "Javascript"

Now substitute the string for any other datatype:

capitalize(5) //=> a.charAt is not a function
capitalize(true) //=> a.charAt is not a function
capitalize(['javascript']) //=> a.charAt is not a function
capitalize(null) //=> Cannot read property 'charAt' of null
capitalize(undefined) //=> Cannot read property 'charAt' of undefined

Anyone who's done a fair amount of Javascript will recognize that mismatched datatypes and null/undefined are a common source of run-time errors. There are, of course, various ways to write safer functions, often referred to as defensive programming:

const capitalize = a => (typeof a === 'string') 
  ? a.charAt(0).toUpperCase() + a.slice(1) : ''

While this is a much safer version, it can add a lot of code cruft, especially when you need these types of checks scattered all throughout your code base. In addition, it forces you to think (and therefore write) in a more imperative way, rather than a more expressive way that functional programming promotes.

The way we deal with null/undefined or type mismatches depends on whether they should be expected and whether the data can be controlled. For example, if we want to capitalize each part of a person's name, and the middle name isn't a requirement in our data, we can expect it to be unavailable (or null) when given to a function. In that case, we'd, ideally, prefer to just skip the function call and let the rest of code continue its execution. This is one of the benefits we get from the Maybe data type.

A Maybe is a Sum Type that can represent one of two other types; a Just or Nothing (or a Some/None, depending on the language). You can think of it as a polymorphic relationship where Just represents a correct or valid value, and Nothing represents an incorrect, invalid, or lack of value (such a null).

Both Just and Nothing act as a container, or wrapper, for raw data. The significance of this is that functions that know how to work with a Maybe can also work with Just or Nothing, even if the raw data is invalid. Each of these wrappers have the same API, allowing them to be interchangeable.

This isn't so different from the way Javascript primitives work. When you execute code such as 'javascript'.toUpperCase(), it's not the string, itself, that has the toUpperCase() function attached to it. After all, string is a primitive, meaning it has no functions or properties. Instead, it's the String() constructor that has the toUpperCase() function, and Javascript will auto-wrap the primitive when calling contructor fuctions/properties on it.

Let's look at some actual code. For the examples in this article we'll be using the Crocks library.

There are multiple ways to construct a Maybe data type, such as using the Maybe constructor itself:

const Maybe = require('crocks/Maybe')

Maybe('javascript') //=> Just "javascript"
Maybe.of('functional') //=> Just "functional"
Maybe.of(null) //=> Just null

The Maybe constructor will always produce a Just. It's recommended to use the Just and Nothing constructors directly, if only for readability:

Maybe.Just() //=> Just undefined
Maybe.Just('javascript') //=> Just "javascript"
Maybe.Nothing() //=> Nothing
Maybe.Nothing('javascript') //=> Nothing

You can also destructure Just and Nothing to tighten up your code:

const Maybe = require('crocks/Maybe')
const {Just, Nothing} = Maybe

Just() //=> Just undefined
Nothing() //=> Nothing

But most of your Maybe types will be produced from helper functions. The focus of this article will be on the safe helper function.

safe takes a predicate function, which returns a boolean, and a value to be applied to the predicate. If the predicate returns true, we get a Just, otherwise, a Nothing:

const Maybe = require('crocks/Maybe')
const safe = require('crocks/Maybe/safe')

const isString = a => (typeof a === 'string') 

safe(isString, 'javascript') //=> Just "javascript"
safe(isString, 5) //=> Nothing
safe(isString, null) //=> Nothing

Safe is curried, allowing us to preconfigure it with a predicate and pass in the data later. For brevity, we'll also switch to Crock's builtin isString function:

const Maybe = require('crocks/Maybe')
const safe = require('crocks/Maybe/safe')
const isString = require('crocks/predicates/isString')

const safeString = safe(isString)

safeString('javascript') //=> Just "javascript"
safeString(5) //=> Nothing

A Maybe (and therefore Just and Nothing) implements a wide range of algebraic structures, one of which is the Functor allowing us to map a Maybe.

One of the rules of a Functor is that when we map a value to another, we get back the same type and structure. If we map an array, we'll get back an array of the same size (with differing values). If we map a Maybe we'll get back a Maybe. We're only affecting the raw data inside. Let's go back to our original caplitalize function and map it to our Maybes:

const safeString = safe(isString)
const capitalize = a => a.charAt(0).toUpperCase() + a.slice(1)

safeString('javascript').map(capitalize) //=> Just "Javascript"
safeString(5).map(capitalize) //=> Nothing
safeString(null).map(capitalize) //=> Nothing

When we map a valid (Just) value, the mapping will unwrap the raw data from our Maybe, pass it into the mapper (capitalize), and re-wrap the result. When we try to map an invalid (Nothing) value, the mapper will be ignored and just return a new Nothing.

The thing to point out here is that our capitalize function is just a regular Javascript function without any type checks or null checks. In fact, we don't have any type/null checks anywhere in our code. That's all abstracted away in the Maybe type. Passing a safeString to capitalize is guaranteed to be error free.

Another thing I'll point out is that an invalid value doesn't have to be only values that produce an error. For example, an empty string could be safely passed to capitalize, but there'd be no point. If we rewrote our safeString function to exclude empty strings from being valid (and rename it to validString) we could avoid the performance cost of executing the capitalize function. This would become more value when implementing expensive operations such as making a service call.

Finally, there will come a time when you're ready to unwrap the raw data and discard the Maybe container. This would usually be at the end of the flow, such as rendering the value on screen, or passing it to a service method. This can be done with Maybe's option function:

safeString('javascript').map(capitalize).option('') //=> 'Javascript'
safeString(5).map(capitalize).option('') //=> ''
safeString(null).map(capitalize).option(null) //=> null

option takes a single parameter, a default value, to use when unwrapping a Nothing. When unwrapping a Just, the default is ignored and the raw data is returned. I would caution against unwrapping your data too early. There isn't anything that can be done to raw data that can't also be done to the same data when wrapped. I've shown an example of transforming wrapped data with map, but there's many more functional applications for wrapped data.

This was very much an introduction to type safety with Maybe. There are many more useful applications with Maybe as well as other structures to help write error free code in an expressive way. I'll be writing a future post on Either, a structure that allows you to work with errors (instead of just avoiding the execution of unsafe code) and eliminating the use of try/catch.

Functional Lenses in Javascript with Ramda

Devin Holloway — Fri, 14 Jun 2019 02:26:57 +0000

Lenses provide a means to decouple an object's shape from the logic operating on that object. It accomplishes this using the getter/setter pattern to 'focus in' on a sub-part of the object, which then isolates that sub-part for reads and writes without mutating the object.

This can bring about multiple benefits. Let's start with the shape decoupling nature of lenses.

Decoupling an object's shape allows for future reshaping of your data while minimizing the effects of the rest of the code in your application. Take, for example, an object representing a person.

const person = {
  firstName: 'John',
  lastName: 'Doe'
}

Now imagine the shape of that object changes such that the firstName and lastName properties are replaced with a single property called name which is itself an object containing properties first and last:

const person = {
  name: {
    first: 'John',
    last: 'Doe'
  }
}

Any code working with that object would now need to be updated to reflect the object's change in shape. This is prevented in OOP through use of classes which hide the data's internal structure and provides access through a getter/setter API. If the shape of a class's internal data changes, all that needs updated is that class's API. Lenses provide the same benefit for plain old objects.

Another benefit to lenses is the ability to write to an object without mutating the object in the process. The non-mutation of data is, of course, one of the staples of FP (functional programming). The problem is, the larger and more complex the data you're working with is, the more difficult it becomes to change deeply nested data without mutations. As we'll see later on, lenses simplify the process with just a couple lines of code no matter how complex your data is.

And finally, lenses are curryable and composable, which makes them fit in well with the FP paradigm. We'll use both of these in later examples.

With the help of Ramda, let's create a lens for working with the person's firstName.

const person = {
  firstName: 'John',
  lastName: 'Doe'
}

We'll start with Ramda's most generic lens creation function called simply lens(). As mentioned previously, lenses use the getter/setter pattern for reading and writing data to our object. Let's create those first.

const getFirstName = data => data.firstName // getter
const setFirstName = (value, data) => ({    // setter
  ...data, firstName: value
})

And then the lens itself:

const firstNameLens = lens(getFirstName, setFirstName)

The lens() function takes two arguments, the getter and setter we defined previously. The lens is then ready to be applied to an object, in this example, the person object. But before we do so I want to point out a few things.

The lens, itself, isn't given a reference to any data. This makes the lens reusable and able to be applied to any data, as long as that data conforms to the shape required of its getter and setter arguments. In other words, this lens is only useful when applied to data that has a firstName property, which could be a person, an employee, or even a pet.
Since the lens isn't tied to any specific piece of data, the getter and setter functions need to be given the data they'll be operating on. The lens will take the object it's applied to and automatically pass it to the supplied getters and setters for you.
Since FP doesn't allow the mutation of data, the setter must return an updated copy of the data that the lens is applied to. In this example, our lens will be applied to a person object so the lens's setter function will return a copy of the person object.

Let's look at how we can use the lens to read from an object using Ramda's view() function:

view(firstNameLens, person) // => "John"

The view() function takes two arguments; a lens, and an object to apply that lens to. It then executes the len's getter function to return the value of the property the lens is focused on; in this case, firstName.

It's also worth noting that view() is curryable, in that we can configure view() with just the lens and supply the object later. This becomes particularly handy if you want to compose view() with other functions using Ramda's compose(), pipe(), or various other composition functions.

const sayHello = name => `Hello ${name}`

const greetPerson = pipe(
  view(firstNameLens),
  sayHello
);

greetPerson(person) // => "Hello John"

Now let's see how we can write to an object with our lens using Ramda's set() function:

set(firstNameLens, 'Jane', person) 
// => {"firstName": "Jane", "lastName": "Doe"}

The set() function also takes a lens and an object to apply that lens to, as well as a value to update the focused property. And as mentioned earlier, we get back a copy of the object with the focused property changed. And, just like view(), set() is curryable allowing you first configure it with a lens and value and provide it with data later.

There's a third lens application function called over(), which acts just like set() except, instead of providing an updated value, you provide a function for updating the value. The provided function will be passed the result of the lens's getter. Let's say we want to uppercase the person's firstName:

over(firstNameLens, toUpper, person)
// => {"firstName": "JOHN", "lastName": "Doe"}

We're also making use of Ramda's toUpper() function. It's the equivalent of:

const toUpper = value => value.toUpperCase()

I want to go back to our original getter and setter functions and look at more concise ways they can be written.

const getFirstName = data => data.firstName // getter
const setFirstName = (value, data) => ({    // setter
  ...data, firstName: value
})

If we're using Ramda for lens creation, it only makes sense to take advantage of Ramda functions for other parts of our code. In particular we'll use Ramda's prop() function to replace our getter and the assoc() function to replace our setter.

The prop() function takes a property name and an object, and returns the value of that property name on that object. It works very similarly to our getter function.

prop('firstName', person) // => "John"

Again, as with most all Ramda functions, prop() is curryable, allowing us to configure it with a property name and provide the data later:

const firstNameProp = prop('firstName')
firstNameProp(person) // => "John"

When using it with a lens, we can configure it with a property name and let the lens pass its data later.

lens(prop('firstName'), ...)

This is also an example of point-free style or tacit programming in that we don't define one or more of the arguments (in this case, person) in our logic. It can be hard to see how this works if you're not used to this style commonly found in FP, but it can make more sense when broken down...

When passing a single argument to a multiary (multi-arg) curried function, it returns a new function accepting the rest of the arguments. It's not until all the arguments are supplied that it executes its function body and returns the results. So when configuring prop() with just the property name, we'll receive a new function that takes the data argument. That matches perfectly with what a lens getter is: a function that takes a data argument.

The assoc() function works the same way, but is designed for writing rather than reading. In addition, it'll return a copy of the object it's writing to, which is the same functionality required by a lens setter.

assoc('firstName', 'Jane', person)
// => {"firstName": "Jane", "lastName": "Doe"}

When used with a lens, we can configure assoc() with just the property name, and let the set() function curry the value and data through.

const firstNameLens = lens(prop('firstName'), assoc('firstName'))

view(firstNameLens, person) // => "John"
set(firstNameLens, 'Jane', person)
// => {"firstName": "Jane", "lastName": "Doe"}

Those are basics of lenses but there are other, more specialized, lens creation functions in Ramda. Specifically, lensProp(), lensIndex(), and lensPath(). These are the functions you'll probably use most often when creating lenses. The generic lens() would be used only when needing to do very customized lens creation. Let's go over each of these specialized lens creation functions.

The lensProp() function takes a single argument; a property name.

const lastNameLens = lensProp('lastName')

And that's it! The property name is all it needs to generate the appropriate getter and setter:

view(lastNameLens, person) // => "Doe"
set(lastNameLens, 'Smith', person)
// => {"firstName": "John", "lastName": "Smith"}

The lensIndex() function works similarly to lensProp() except it's designed for focusing in on an array index, and therefore, you pass it an index rather than a property name. Let's add an array of data to our person to test it out.

const person = {
  firstName: 'John',
  lastName: 'Doe',
  phones: [
    {type: 'home', number: '5556667777'},
    {type: 'work', number: '5554443333'}
  ]
}

Then when applying the lens...

const firstPhoneLens = lensIndex(0)

view(firstPhoneLens, person.phones)
// => {"number": "5556667777", "type": "home"}

set(
  firstPhoneLens, 
  {type: 'mobile', number: '5557773333'}, 
  person.phones
)
// => [
//  {"number": "5557773333", "type": "mobile"}, 
//  {"number": "5554443333", "type": "work"}
//]

Notice how when applying the lens we have to pass in person.phones. While this works, it's less than ideal because now we're relying on knowledge of the object's shape in our general application code, rather than hiding it in our lens. In addition, when applying the lens with the set() function, we get back the array of phones, not the person. This emphasizes that whatever object you give the lens application, the same is what you get back. The likely next step would be to merge the new array of phones back into the person object. This would, of course, need to be done in a non-mutating way... something that Ramda could handle easily. However, it'd be better to not even have to take that extra step. That leads us to the third specialized lens, lensPath() which is designed for focusing in on nested data.

const homePhoneNumberLens = lensPath(['phones', 0, 'number'])

view(homePhoneNumberLens, person) // => "5556667777"
set(homePhoneNumberLens, '5558882222', person)
// => {
//  "firstName": "John", "lastName": "Doe"
//  "phones": [
//    {"number": "5558882222", "type": "home"}, 
//    {"number": "5554443333", "type": "work"}
//  ]
//}

As you can see, lensPath() takes an array with path segments leading to the nested data that we want focused. Each path segment can be a property name or an index. Since we're giving it the root person object, we get back a full copy of the person object with just the home phone number changed. In my opinion, this is where the lens feature really starts to shine. Imagine if we wanted to duplicate the result of the set() function above, but with regular Javascript. Even with the latest features, such as spreading and destructuring, we might end up with something like the following:

const [homePhone, ...otherPhones] = person.phones
const updatedPerson = {
  ...person,
  phones: [
    {...homePhone, number: '5558882222'},
    ...otherPhones
  ]
}

That's quite a bit of work compared to the two line example using lenses!

One of the more powerful features of lenses is their ability to be composed together with other lenses. This allows you to build up new and more complex lenses from existing ones:

const phonesLens = lensProp('phones')
const workPhoneLens = lensIndex(1)
const phoneNumberLens = lensProp('number')

const workPhoneNumberLens = compose(
  phonesLens, 
  workPhoneLens, 
  phoneNumberLens
)

view(workPhoneNumberLens, person) // => "5554443333"

The result is not too different from using a single lensPath(). In fact, if I had no need for the individual phonesLens and workPhoneLens in other contexts, I'd probably just use a lensPath() instead. However, the nice thing about this approach is that no one lens has the full knowledge of the entire shape of a person. Instead, each lens just keeps track of their own pieces of shape, relieving that responsibility from the next lens in the composition. If we were to, for example, change the property name phones to phoneList, we'd only need to update the lens responsible for that piece of shape (phoneLens) rather than updating multiple lenses that happen to overlap that path.

And that's a rundown of the features and benefits of functional lenses in Javascript with Ramda.