DEV Community: Pierluigi Pesenti

10x Readability with Higher-order Predicates

Pierluigi Pesenti — Thu, 05 Jun 2025 10:17:22 +0000

Predicates

A predicate is a pure function that accepts any arguments and returns a boolean.

const isEven = (n: number) => n % 2 === 0;

console.log(isEven(2)); // true

Predicates are fundamental in programming, and their usage is widespread across various paradigms.

Higher-order Functions

A higher-order function is a function that accepts arguments and returns a specialized (partially-applied) function.

const times = (m: number) => (n: number) => n * m;

// e.g. inline:
const doubledInline = numbers.map(times(2));

// e.g.:
const double = times(2);
const doubled = numbers.map(double);

When the outermost function is invoked, it returns a new function with the first argument "baked in," awaiting the second argument. This is known as currying.

Currying enables partially-applied functions to be stored in variables or used inline. In both cases, it simplifies extraction of functions that would otherwise require explicit inline parameters. Those functions can now be used point-free.

Point-free Style

Point-free programming has nothing to do with points in a geometric sense or with the dot-syntax. Here, a "point" refers to an argument.

const doubledAgain = numbers.map((n) => n * 2);

In this example, n is the "point."

This style introduces some issues:

The 2 is hardcoded. The only alternative without resorting to a higher-order function (HoF) would be to retrieve it from scope, compromising purity.
It is less readable compared to previous examples.

Consider the earlier examples:

const doubledInline = numbers.map(times(2));
// ...
const doubled = numbers.map(double);

In both cases, the .map() calls are point-free. Using a higher-order function (HoF) allows the 2 to be embedded directly into the function—either inline (times(2)) or pre-stored as a partially-applied function (double).

Higher-Order Predicates: The Key to 10x Readability and Composition

A higher-order predicate is a function that accepts arguments and returns a specialized predicate.

By using higher-order predicates, you can achieve the same level of readability and reusability as seen with mappers, but applied to filter functions (or similar methods like find, every, and some).

const isDivisibleBy = (divisor: number) => (dividend: number) => dividend % divisor === 0;

[1, 2, 3, 4].filter(isDivisibleBy(2)); // [2, 4]

This approach encourages the creation and organization of reusable predicates and higher-order predicates into semantic groupings, enhancing discoverability and readability. Additionally, they are straightforward to unit test.

For a ready-to-use library, consider fp-filters, a curated collection of 130+ predicates. It is fully typed, 100% tested, and open for contributions.

A switch is a code smell

Pierluigi Pesenti — Sun, 01 Jun 2025 07:56:00 +0000

A switch statement smells.
For several reasons, and you should never use it.

Let's make some arguments:

It is verbose and *WET*
Counter-intuitive fall-trough behavior
It is a statement, not an expression

Let's get started with the main argument of this article:

It is verbose and WET

Look at the following example:

Example 1

const quantity = 1;

switch (quantity) {
    case 0:
        console.log('You have none. Sorry');
        break;
    case 1:
        console.log('You have some. Keep going!');
        break;
    case 2:
        console.log('Someone here is rich!');
        break;
    default:
        console.log('No cases matched');
}

It shows a very common use of a switch. In this example the intent is to log different messages based on a quantity.

Repetitions are everywhere:

Every value is prefixed with case;
Every log message is wrapped in a console.log call;
Every case block is ended with a break;

What happens in the example is basic mapping.
We should use a map to map things.

In JS an object is a map. A Map class is also available with different APIs.

Here is the revised code:

Revised 1

const map = {
    0: 'You have none. Sorry',
    1: 'You have some. Keep going!',
    2: 'Someone is rich!',
};
console.log(map[quantity] ?? 'No cases matched');

Benefits

The mapping overhead goes down to the bare minimum, the association case -> output is addressed by a simple colon. It can't get *DRY*er than that (We could eventually use tuples)
The log is invoked only once with the proper map index as content
A nullish coalescing operator (??) or a logical OR (||) takes care of the default value in the case of no matches
All the repetitions found in the original example are gone. After all, all we wanna do is log something
No break or default keywords are needed
the intent of mapping a quantity to a message is much more clear
No 2-deep nesting needed
161 chars vs 319 (helps with readability)
Last but not least while the invocation of the console.log is still a statement, its argument is now an expression. Which can be easily extracted and given a name. The declaration of the map is technically also a statement here, but it could easily be an expression if inlined or passed as an argument (see Chapter 3).

Counter-intuitive fall-trough behavior

A switch statement can do several different things based on how we use it (and this is not necessarily a good thing). It is broken by design and can be a nightmare to decode.

Let's have a look at an example that leverages the fall-trough directly from MDN doc page:

Example 2

const animal = 'Giraffe';
switch (animal) {
    case 'Cow':
    case 'Giraffe':
    case 'Dog':
    case 'Pig':
        console.log('This animal is not extinct.');
    break;
    case 'Dinosaur':
    default:
        console.log('This animal is extinct.');
}

This is a common pattern to have several values triggering the same behaviour, but it works because of a secret rule that says: "if you leverage fall-trough you still need a break after doing something". Omitting the break after the first console.log would trigger the second too, despite the case not being 'Dinosaur' or unmatched (default).

Let's verify this behaviour with a distilled example:

Example 3

switch (1) {
  case 1:
  case 2:
    console.log('either: 1, 2');
    break;
  case 3:
  case 4:
    console.log('either: 3, 4');
    break;

  default:
    console.log('something else');
}

// logs "either: 1, 2"

The output is what we expect, thanks to the break after the first log. We are using the fall-trough just trough cases, not through their code blocks and this is fundamental. If we get rid of the breaks entirely once a condition is met, all possible actions for every subsequent case (even unmatched will fire).

Let's simplify again:

Example 4

switch (2) {
  case 1:
    console.log('1');
  case 2:
    console.log('2');
  case 3:
    console.log('3');
  case 4:
    console.log('3');
}
// outputs 2, 3, 4 because we are switching on 2, if we were switching on 1 it would log 1, 2, 3, 4

Things can get even absurder when we switch on true which is a common pattern to assess a bunch of conditions that need subsequent actions.
Another example from same MDN page:

Example 5

switch (true) {
  case "fetch" in globalThis:
    // Fetch a resource with fetch
    break;
  case "XMLHttpRequest" in globalThis:
    // Fetch a resource with XMLHttpRequest
    break;
  default:
    // Fetch a resource with some custom AJAX logic
    break;
}

This works because fall-trough is prevented and because the two conditions for the two cases are mutually exclusive.

The mechanism of the switch works so that an expression (yes, not just values) is switched onto and every case also presents an expression (again, not just values). The two expressions are strictly compared (using triple equal sign) to check a match.

We could not have a fall-trough implementation when switching on true:

Example 6

switch(true) {
  case false: 
    console.log('Log false');
  case 1: 
    console.log('Log 1');
  case true: 
    console.log('Log true');
}
// logs: Log true (expected)

This code barely stands as the matching case is last...
But what happens if we move the last case in the first position is not so expected:

Example 7

switch(true) {
  case true: 
    console.log('Log true');
  case false: 
    console.log('Log false');
  case 1: 
    console.log('Log 1');
}
// logs: Log true, Log false, Log 1

You can obviously deal with it if you know how it exactly works but this is just a bad API no excuse, and should be avoided.

Let's now rewrite the animals example using a map:

const mapAnimalsExtinct = {
    Cow: false,
    Giraffe: false,
    Dog: false,
    Pig: false,
    Dinosaur: true,
};
console.log(
    mapAnimalsExtinct[animal]
    ? 'This animal is indeed extinct'
    : 'This guy is alive and kicking'
);

The values are now repeated but that's content and much more database-y, so to be expected. Repetition in data has nothing to do with repetition in code as it is declarative and declarative code depicts intents and content.

To minimize it further we could annotate only the extinct animals from the original complete list.

It is a statement, not an expression

Statements do things, expressions are evaluated down to values.
Statements can be placed only in the body of code block, expressions can be place anywhere (inlined anywhere, arguments default values, etc.).
Expressions are referentially transparent and always correspond to their computed value.
Many statements can be replaced by expressions.

The topic is complex and will deserve its own article.

Conclusion

Switch is archaic, verbose, repetitive and poorly designed.
Since most often it is used to map certain values to certain behaviors, we can use maps instead, having a leaner and immediately readable code.

Thanks.