Getting Funky With Filters

Those are the basic conditions. Each of those can be run as unique, independent functions, each can be used as a filter, and each is testable in isolation. And (and here's the power of functional programming) each is composable.

What does this mean? Let's start by writing out each of those four as a function in themselves:

const isOnline = user => user.online;
const isArabic = user => user.language === 'Arabic';
const isFemale = user => user.gender==='Female';
const likesCrimson = user => user.favorite_color==='Crimson';

And that works fine. Each one is testable against an array of objects, each returns a true or false based on the user's property matching as we want, each does what it says on the box. Incidentally, in terms of conventions, functions that return a true or false are called predicate functions (as in "decisions are predicated on this thing").

But it's ugly, and inelegant. I don't like it. Nope. Nuh-uh.

Why not? Because each line does the exact same thing: given a property, find a given matching value on some object. They all do the same thing. So we're repeating code unnecessarily. What can we do? We can step back one step further. We can abstract that out, by writing a generic function, which we'll call filterByProp(). I use the full name like that, because I also have a sortByProp(), a findByProp() and a reduceByProp(), all of which use the same basic idea: given an array of objects, work with a given property. Here's how this one might look:

const filterByProp = (prop) 
  => (val) 
    => (obj) => obj[prop]===val;

That's it. That's the whole shebang. We start by calling filterByProp() with the property name we want to filter by, and we get a function back. That function is waiting for a value to which we compare that property. So we call the function we just got back, passing a value, and we get another function back, that's waiting for the object itself. This third function? That's the one that our filter function can consume.

And here's one way to look at using it:

const byOnlineStatus = filterByProp("online");
// byOnlineStatus is now a function, waiting to be
//  given a value to match that property against.

const isOnline = byOnlineStatus(true);
// and isOnline is now the same function as we wrote
//  above: isOnline = (user) => user.>

What we've done here is functional currying. We've started with a function, and passed in a value, and got back a function awaiting a second value. When we pass in that second value, we get a function awaiting the third, the final object against which we'll check. A shorthand version of the same isOnline() might look like this:

const isOnline = filterByProp("online")(true);
const isArabic = filterByProp("language")("Arabic");
const isFemale = filterByProp("gender")("Female");
const likesCrimson = filterByProp("favorite_color")("Crimson");

Again, they each work in isolation, they can each be tested, both in isolation and in integration, they are tidy, and they are elegant.

When I speak of elegance here, I mean that, within our filterByProp() function, I have zero knowledge of what's going on inside our object. I don't hard-code into the function itself what those properties or values might be, I simply create a function that says "Hey, I've got some object - tell me if it has this property-value pair". It's object-agnostic.

So with those pieces, we could now do:

const filteredList = users.filter(
  user => isOnline(user) &&
         (isArabic(user) ||
           ( isFemale(user) && likesCrimson(user) 
         )
       );

Much more succinct, much more readable, our filter has become... well wait. Not so much. In order to compose our functions, we need to call them all inside our outer function. The way we've done this, you'll note that each of our inner filter functions is being called independently. Not so pretty, not so well documenting.

What to do, what to do...

Here's my thinking: what if we had a mechanism that would let us compose those functions into larger pieces, each of which can simply be plugged in as a filter function?

To do this, we'll need functions that combine our filters, and we want to combine them in two different ways: we want to replace the && with a function we'll call and(), and replace the || with a function we'll call or(). Each of these should take multiple functions as parameters, and return a function that checks if all the conditions of those functions are met (in the case of and), or if some of them are met (in the case of or). So let's dive in:

// So we pass in any number of parameters, and we turn
//  that into an array of funcs. We want every func in
//  that array to return true for a given object.

const and = (...funcs) => obj => funcs.every(func => func(obj) ) 

// now to use this, we can combine our functions, taking
//  (isFemale(user) && likesCrimson(user) ) and turning it to:
const isFemaleAndLikesCrimson = and(isFemale, likesCrimson);

// The or function is exactly the same, except for the function
//   we use on the array of funcs:
const or = (...funcs) => obj => funcs.some(func => func(obj) );
// Here, we are saying "if one or more of these pass, I'm good!"

// with this one, we can combine the next level out: We've gone from
//  (isArabic(user) || (isFemale(user) && likesCrimson(user) ) )
// to
//  (isArabic(user) || isFemaleAndLikesCrimson)
// so next we simply:
const isArabicOr_IsFemaleAndLikesCrimson = or(isArabic, isFemaleAndLikesCrimson);

// and, for the final piece of our complex filter function:
const isOnlineAnd_IsArabicOr_IsFemaleAndLikesCrimson = and(isOnline, isArabicOr_IsFemaleAndLikesCrimson);

Note that I used the underscores simply to denote groupings, but they're not necessary. I worked from the innermost combination out, composing larger and larger functions that, as a final result, return the exact same data type as the composed functions. Why does that matter? They become interchangeable. Our ridiculously-long-named function can now be used as a filter function's callback:

const filteredList = users.filter(isOnlineAnd_isArabicOr_isFemaleAndLikesCrimson);

So that function we pass into the filter function is now complete and self-documenting. We can see at a glance what we're filtering for (though I would really prefer a way to delineate the separation between ors and ands - if anyone has suggestions, I'm open to them!), we can read what's happening, we can test each smaller part in isolation, and each larger part as we grow, and we have a great start for a functional toolkit.

I suppose, if we wanted to keep it nice and legible, we could back it up a small step:

const filteredList = users.filter( 
  and(isOnline, 
    or( isArabic, 
      and(isFemale, likesCrimson)
    )
  )
);

That is a more readable version. The outermost and(...) is the function actually being called by the filter(...), and that one is simply composing its two parameters into an array on the fly, and so on, down the line.

What's the takeaway?

Good question, that. First, that we can compose small, simple functions into very complex ones that still do simple things. Second, that those small parts, while unaware of things outside themselves, can be very powerful with those things of which they are aware. And third, that we have the beginnings of a functional library:

// This is a great tool to add to a functional library, and one you can use over and over for other situations.
const filterByProp = (prop) => (value) => (obj) => obj[prop]===value;

// the two functions, and() and or(), are powerful composers.
const and = (...funcs) => (obj) => funcs.every(func => func(obj) );
const or = (...funcs) => (obj) => funcs.some(func => func(obj) );

There are others, we'll continue to grow this collection, but this is a good place to start.