DEV Community

Cover image for The Trials and Tribulations. A Fool's Guide To Writing Functional JS (Part 4)
Fahad Hossain
Fahad Hossain

Posted on • Updated on • Originally published at mildlyboring.com

The Trials and Tribulations. A Fool's Guide To Writing Functional JS (Part 4)

It's been a while since my last article so, hopefully you didn't forget what we last discussed. Throughout the last 3 articles I alluded to some nifty tricks and nice-ties like compose. So in this article we will try to cover some of these topics.

Let's see some problems that we come across when starting out our FP journey in JS.

Problem #1

If you have been writing functional code, or even just trying to avoid mutations and side-effects, you probably ended up writing something like this

const data = {
  /*...*/
}; // some data
const result = doSomethingCompletelyDiff(doSomethingElse(doSomething(data)));
Enter fullscreen mode Exit fullscreen mode

At some point, making this kinda nested function calls becomes inevitable; specially if you don't want to make really specific, single-use functions. But this kind of function calls are not only ugly to look at, sometimes they are difficult to follow as well. Specially if you add some higher-order functions in between, then you've got a nasty mess of parentheses.

What if we had something that could combine multiple functions to a single function?

Solution:

We do have precisely that exact tool. (Un)surprisingly, it's another one of those things that we borrow from math.

Let's see it in math first.

Lets define a function f(x)

And another function g(x)

Lets take a letter y and let its value be...

We can see our old friend nested function call here again... So how did math come up with a solution?

They made an operator, of course. This operator allows you to define a function by composing multiple functions and as such, it's called the composition operator. Visually, it looks like a tiny circle.

Here's composition operator put to use,

Here, h is defined as the composition of g and f. Functionally, calling h(x) is the same as calling f(g(x)) So now, we can do this

"Great" I hear you say, "How does that help me in code, I can't just put a big ol' dot between two functions in JS can I?"

You can!

No, not put a big ol' dot... you can compose functions in JS just not using an operator.

It goes something like this

const newSuperFunction = compose(lastFn, secondFn, firstFn);
Enter fullscreen mode Exit fullscreen mode

Doesn't look too horrible, if you ask me 🤷

"But where did this compose function come from, and how do I get one?" I hear you say

I'm glad you asked, remember our old friend the fold (reduce)? We can very easily define compose using a right fold (we discussed a left fold before, this is the same thing but from the other direction).

const compose = (...funcs) =>
  funcs.reduceRight(
    (fx, gx) => (...args) => gx(fx(...args))
  );
Enter fullscreen mode Exit fullscreen mode

Here, our compose function takes a variadic number of arguments, all of which are functions.

Because of the rest operator we get the functions as an array, so we can call the built-in reduceRight function from the array prototype.

Then, we pass in a argument to the reduceRight call.

We pass a function that receives two functions as arguments, and returns an inline variadic function that calls the two functions successively with its arguments.

The variadic (any number of arguments) bit was added so that we can compose non-unary (more than one argument) functions too.

Happy composing, Enjoy!

Problem #2

Once you understood map, filter and reduce you just can't go back. You write code that looks like this

const dataSet = [
  /*...*/
]; // Some dataset
const finalData = dataSet
  .map(someTransformation)
  .map(someFurtherTransformation)
  .filter(somePredicate)
  .filter(anotherPredicate)
  .map(evenMoreTransformation)
  .reduce(combinatorFunction);
Enter fullscreen mode Exit fullscreen mode

While this code is very contrived but you get the idea. If you don't want to make a bunch of one-off transformations and predicates you end up doing this.

Even if it might not seem like a problem at first, you will start to see a crash coming from miles away as soon as your dataset becomes large enough.

The problem with this kind of code is that every map and filter and reduce call is an iteration. In imperative code you might be used to doing a lot of transformation and filtering out in a single loop, which looks almost impossible to do here.

Solution:

Just a word of warning, there are better solutions out there. But, for now we can discuss some simple ones that will help you write better code regardless of better solutions. If these do not help your use case enough, do a little digging into transducers.

  • Combine successive transformations/maps
  .map(someTransformation)
  .map(someFurtherTransformation)
Enter fullscreen mode Exit fullscreen mode

Can be rewritten using our friend compose like this

  .map(compose(someFurterTransformation, someTransformation))
Enter fullscreen mode Exit fullscreen mode

While the benefit may not be obvious, what you are essentially doing is that you are running 2 transformations in a single iteration rather than running 2 iterations with 1 transformation each. Which means, 1 less iteration but the same result

  • Combine successive filters

You might get the idea that we can combine filters the same way we combined maps.
However, the moment you go to do such a thing, you realise that you forgot that composing predicates just won't work.

But we can get around that by implement a logical and function to combine predicates, since that's essentially what two successive filters do anyway.

Let's try to implement a binary and function

  const and = (pred1, pred2) => (...args) => pred1(...args) && pred2(...args);
Enter fullscreen mode Exit fullscreen mode

So now we can rewrite this

  .filter(somePredicate)
  .filter(anotherPredicate)
Enter fullscreen mode Exit fullscreen mode

to this

  .filter(and(somePredicate, anotherPredicate))
Enter fullscreen mode Exit fullscreen mode

You can combine more than two predicates by nesting calls to the and function. But I recommend checking out Ramda's allPass and both functions.

Why re-invent the wheel when the wheel is so nice?

Problem #3

I write too many helper functions like compose, pipe, etc.

This is a comment I hear from friend very often. And... I'll admit, I had this problem too. While writing helper functions isn't bad, it can be bad when you spend more time writing them than writing your business logic.

The reason why so many JS devs have this problem is that our language gives the very basic tools to get us hooked on FP and then leaves us high and dry and wanting more. So we end up implementing a lot of basic fundamental FP constructs ourselves.

Solution (not really, but it is what it is)

A lot of this can be avoided by adding a Functional utility library to your toolchain. I highly recommend Ramda, because it gives a lot of functionality at a very reasonable file size. All of its functions are at least on par with some language built-in implementations, if not better, in terms of performance. And the cherry on top, its tree-shakeable; so almost any build system like webpack or rollup can remove the functions you don't use from the final JS bundle.


That's enough problems for a day

Enjoy writing more FP code. I'll try to write about a few more problems and solutions.

Till then, Peace ✌️

peace

Latest comments (11)

Collapse
 
canmingir profile image
Can Mingir

Great post!

Collapse
 
pentacular profile image
Info Comment hidden by post author - thread only accessible via permalink
pentacular

Or you could just ... use variables.

Then you can also have sensible names.

And it won't be any less functional.

Collapse
 
fa7ad profile image
Fahad Hossain • Edited

Sure, I never said you couldn't use variables. Which of the problems do you think can be solved by using variables? I never said anything about having sensible names, are you confusing this post with some other post?

Collapse
 
pentacular profile image
pentacular

Since you're suggesting point-free composition it might be a good idea to also consider the alternative.

const deduplicated = deduplicate(data);
const inverted = invert(deduplicated);
...

Each approach has its strengths and weaknesses, after all.

Collapse
 
ayabongaqwabi profile image
Ayabonga Qwabi

"...I can't just put a big ol' dot between two functions in JS can I? " that part put me in stiches,
Great article man🙂

Collapse
 
fa7ad profile image
Fahad Hossain

Glad you enjoyed it 😊

Collapse
 
teamroggers profile image
Rogier Nitschelm

This is a great post! Good inspiration for people like me who enjoy declarative programming and want to keep them functions tidy and clean.

Collapse
 
pentacular profile image
Info Comment hidden by post author - thread only accessible via permalink
pentacular

There is no declarative programming here.

Collapse
 
fa7ad profile image
Fahad Hossain

@pentacular There is no actual code here. These are issues that I've faced when I was starting out, and I thought were worth sharing.

Thread Thread
 
pentacular profile image
pentacular

I'm not objecting to the article -- just pointing out that it's not declarative.

And there's nothing wrong with that.

Collapse
 
fa7ad profile image
Fahad Hossain

Thanks. Glad you enjoyed it 🙂

Some comments have been hidden by the post's author - find out more