In a previous post, we started building some very atomic functions. To recap those, they looked like:

  const isEqual = (comparator)=>(value)=>value===comparator

  const isGreaterThan = (comparator) => (value) => value > comparator

const isLessThan = (comparator) => (value) => value < comparator

  const isNot = (value) => !value

  const and = (conditions)=>(value)=>conditions.every(condition => condition(value) )

  const or = (conditions)=>(value)=>conditions.some(condition=>condition(value) )

These core functions can be combined in various ways. For example, we can define a isNotEqual function by simply composing the functions isNot() and isEqual:

const isNotEqual = (comparator) => (value) => isNot(isEqual(comparator)(value) )

const isLessThanOrEqualTo = (comparator) => (value) => isNot(isGreaterThan(comparator)(value))

const isGreaterThanOrEqualTo = (comparator) => (value) => or(isGreaterThan(comparator), isEqualTo(comparator))(value)

// The same could be done simply by combining the isNot function and the isLessThan:
const isGTE = (comparator) => (value) => isNot(isLessThan(comparator)(value)) 

const isLessThanOrEqualTo = (comparator) => (value) => or(isLessThan(comparator), isEqualTo(comparator))(value)

// We could also do this:
const isLTE = (comparator) => (value) => isNot(isGreaterThan(comparator)(value))

// The isBetween simply masks the two actual functions, conditionally returning the appropriate one.
// This one was formatted differently, simply to fit in the browser window.
const isBetween = (inclusive) =>
  (min, max) => 
    (value) => 
      inclusive ? isBetweenWeak(min, max)(value) :
                  isBetweenStrict(min, max)(value)

// The first excludes the min and max values...
const isBetweenStrict = (min, max) =>
  (value) => 
    and([
      isGreaterThan(min), 
      isLessThan(max)
    ])(value)

// ... while the second accepts them as in-range.
const isBetweenWeak = (min, max) =>
  (value) =>
    and([
      isGreaterThanOrEqualTo(min),
      isLessThanOrEqualTo(max)
    ])(value)

Moving on...

Those functions all return a true or false value. I have given them descriptive names, that tell you two things: first, that they're a Boolean function (they check if a given value is something), and second, what the function itself does. isNotEqual() is very descriptive. Each of those functions was designed for a specific use: a modular approach to writing filter functions.

These are by no means the limit of what we might want in a functional filter library, simply a starting point. But the point of this exercise is to write code that becomes more self-documenting, so let's try an example of how that might look.

// given this array... 
const array = [1, 2, 4, 7, 3, 2, 9, 11, 5, 27, -3, 8];

// we can write this, and it works fine.
const filteredArray = array.filter(function(value){
  return value<=7;
})

// or with our library of handy functions, we could partially apply
//   one, and use that:
const isLessThanOrEqualTo7 = isLessThanOrEqualTo(7);
// we now have a function that is ready to be used in a filter,
//   but that also describes its intent.
const filteredArray2 = array.filter(isLessThanOrEqualTo7);

So the second, while it seems a little more verbose, does the same thing. But it also tells us exactly what it is doing. It is self-documenting. As much as possible, it's good practice to use named functions for filter(), map(), sort() and reduce(), or indeed, nearly any callback function. Let's see another example.

We haven't created one yet, but perhaps we want to filter our elements based on even or odd values. We could simply add this function to our functional filter collection:

// A number is even if, when divided by two, it has a remainder
//   of zero.
const isEven = (value) => isEqual(0)(value%2)

// We could also have done:
const isEven2 = (value) => value%2 === 0

So the above function could be used with our same array, exactly as is:

const array = [1, 2, 4, 7, 3, 2, 9, 11, 5, 27, -3, 8];

const filteredArray = array.filter(isEven)

And, just like that, the filter tells us exactly what it's filtering for. But hey, what if we wanted to change that, to filter for even-numbered array indexes? Can we DO that? As a matter of fact, yes:

const array = [1, 2, 4, 7, 3, 2, 9, 11, 5, 27, -3, 8];

// we write a named function, in order to keep filter self-documenting.
const indexIsEven = (value, index) => isEven(index);

const filteredArray = array.filter(indexIsEven)

Remember, a callback passed into a filter takes up to three parameters: a value, an index, and a reference to the original array. In our case, we wrap our isEven() in a function that takes the first two parameters, and apply it to the second. The value parameter is never used.

Again, our function, indexIsEven(), is intended to be very self-documenting. It tells us specifically what it's doing, it tells us that it's doing a comparison and, if we use a consistent naming style, the Is in there tells us it will return a Boolean.

But what if...?

What if your array was something other than numbers? Would our functions still work? We can test them:

const array = ['Lara','Bill','Bob','Jenny','Bill','Lara','Denise'];

// Simply for the convenience of self-documenting names, let's 
//  create a partially applied version of the isEqual function here.
const isNamed = (name) => isEqual(name)

// And we can actually apply that function. 
const isNamedLara = isNamed('Lara')

console.log( array.filter( isNamedLara ) )

Note that we didn't need the isNamed function, we could have simply said const isNamedLara = isEqual('Lara'), but we are writing functions that have meaningful, self-documenting names here!

If we wanted to use our handy-dandy functional filter bits with more complex data types (for example, objects), we need to create a few more useful utility functions. Here are a couple we might find handy:

• a function to retrieve a given property from an object;
• a function to tell us if an object has a given property.

Let's start there:

const prop = (property) => (obj) => obj[property];
const has = (property) => (obj) => obj.hasOwnProperty(property);

Boom. That's all. The first one, prop()(), takes a property name, then returns a function. That returned function expects an object, and returns the given property name from that object.

How might we use that? Let's play:

const users = [{
  first_name: 'Bill',
  last_name: 'Tyler',
  online: true,
  friends: ['Janice','Reuven','Harssha']
},{
  first_name: 'Janice',
  last_name: 'Ogilvy',
  online: false,
  friends: ['Bill','Tamika','Nathaniel']
},{
  first_name: 'Bill',
  last_name: 'Maxwell',
  online: false
  // Note that he has no friends...
}]

// This line will partially apply our prop function, and return
//  us a function that wants an object.
const firstname = prop('first_name')

// Here, we use that function, and it becomes the return value
//  for our map method. We're taking the array of users object,
//  an converting it to an array of users first names.
console.log( users.map( firstname ) )

Let's use the has function now. We'll partially apply that. We do this by calling the first function, and assigning the returned function to a variable. This is called partial application, as we haven't provided all the parameters to completely apply the function.

// The function that gets returned is assigned to the variable.
const hasFriends = has('friends')

// And now we use that function as our callback.
const folksWithFriends = users.filter(hasFriends)

That last one would return only those users who have a friends property, thus removing the last Bill.

const propIsEqual = (property) =>
  (comparator) =>
    (object) =>
      isEqual( comparator )( prop( property )( object ) ) )


// The above is three functions, each partially applied. We can
//   apply them step-by-step, like this:
const firstNameIsEqual = propIsEqual('first_name')
const firstNameIsBob = firstNameIsEqual('Bob')

// Or we can jump straight to the final step, like this:
const isOnline = propIsEqual('online')(true)

console.log( users.filter( isOnline ) )

Again, our functions names are descriptive and self-documenting. We can tell, at a glance, we're filtering the users array for those users online. We could also continue to compose those functions, by wrapping them in other functions:

// If we want, we can reverse our isOnline.
const isOffline = (object) => isNot( isOnline( object ) )

Note that my isOffline() function requires a single parameter, and that one is the one required to complete our partially applied isOnline() function.

Is there a POINT here?

Actually, I think I have flogged that particular horse. Some of these examples have gotten a little silly, and may seem overly complex for simple problems. And you're not wrong. I wrote a complete function to replace the =, for goodness sake!

And yet... for those who want to be able to glance at code, and have it tell a story, then having descriptive functions that we can reuse, compose, and extend are very useful.

I have tried to use descriptive names for my functions, often sacrificing terseness of code for clarity of description. But, as you become more comfortable with composing functions (combining them one with another, in different combinations and permutations), you may find some functional libraries to be useful.

Much of what I've written here, and in the first Functional Legos post, is very primitive. There are great libraries that do much the same thing, in a far more concise and consistent way. Over the next few weeks, I'll explore one of them: the Ramda FP library.