DEV Community

JS Functional Concepts: Pipe and Compose

JoelBonetR 🥇 on January 02, 2023

Function piping and composition are concepts from functional programming that of course are possible in JavaScript -as it's a multi-paradigm progra...

Read full post

Joshua Baker • Jan 2 '23

I'd like to point out that the pipeAsync and composeAsync functions are examples of monadic composition! 😁

JoelBonetR 🥇 • Jan 2 '23

Indeed they are! 👌🏼😁

Mahmoud Harmouch • Jan 10 '23

Thanks for sharing such a neat concept. Also, +1 on using JSDoc (Get the TS code outta my face. Kidding, keep it.).

JoelBonetR 🥇 • Jan 10 '23

😂

Mahmoud Harmouch • Jan 10 '23

export const pipeAsync: any =
  (...fns: Promise<Function>[]) =>
  (input: any) =>
    fns.reduce((chain: Promise<Function>, func: Function | Promise<Function> | any) => chain.then(func), Promise.resolve(input));

JoelBonetR 🥇 • Jan 10 '23

To be fair in this situation it can, effectively, be any 😅
The return type would be the return type of the last function called and the type to pass to the next function would be the output type of the one before, but I honestly don't know how to express that in the TS type system nor if its possible. 🤯

Mahmoud Harmouch • Jan 10 '23

These situations always keep me thinking about why I am using TS in the first place. You will end up spending so much time figuring out the types in these tricky situations, which is NOT a business problem to work on in the first place. That's why I would love to revert back to JS, anytime.

JoelBonetR 🥇 • Jan 10 '23

Because the absence of types (nor TS nor JSDoc+TS Pragma ) leads sooner or later to non-expected paths that can break the app in runtime, which is a business problem that will rain as sh*t over the dev team (Imagine you spent 200k on a marketing campaign and the app crashes avoiding the conversion that could eventually amortize the costs plus benefits).

Are the types necessary in every single App? No, they aren't.

Still it's recommended to have them in most apps. On the other hand, JSDoc + TS Pragma (remember that JSDoc alone does nothing but printing an informative text, you need TS Pragma to get type checks on dev time) is better than nothing, but TS has much more features than that.

Mahmoud Harmouch • Jan 10 '23

Because the absence of types (nor TS nor JSDoc+TS Pragma ) leads sooner or later to non-expected paths that can break the app in runtime, which is a business problem that will rain as sh*t over the dev team

Yep. Although the absence of types may not be considered a major problem by some, me included, I believe that not following best practices is what ultimately causes more issues in web development. By adhering to established conventions and standards, we can avoid many of the potential problems that can occur without these guidelines. In addition, following best practices often leads to code that is easier to read and understand, which can save time and frustration for all parties involved.

But, the thing is that major business issues, even though I don't have data but from what I have experienced, are not necessarily caused by the absence of types. I think there is a correlation between the two. But, the relation is not causation. The absence of types doesn't necessarily lead to rain as sh*t over the dev team. Know what I am saying?

Are the types necessary in every single App? No, they aren't.

Agree.

JoelBonetR 🥇 • Jan 10 '23 • Edited

Of course not, the main issue is not having tests.
Key in the discussion here being that coding in TypeScript is faster than vanilla JS + JSDoc + TS Pragma, you may never seen it this way but look:

/**
 * Sums two numbers
 * @param  {number} n1
 * @param  {number} n2
 * @returns {number}
 */
const sumTwoNumbers = (n1, n2) => n1+n2;

/** Sums two numbers */
const sumTwoNumbers = (n1: number, n2: number) => n1+n2;

As well as more reliable.
To get a similar reliability with JSDoc you need to ensure JSDoc is added and maintained through automatisms in the linter and run this step in the PR's pipeline, at least (i.e. ESLint plugin JSDoc) and it takes more to configure than what it takes to configure TS most of the time.

Keep in mind that using JSDoc and TSPragma you are just using one little piece of TS, which is about type definition and type reports (and it doesn't even cover it entirely).

If you just need those features, then add TS and just use those features 😂

Do you dislike interfaces? Fine, don't use them, if you are working in FP instead OOP, interfaces doesn't even make sense (in FP all functions are interfaces).

It is not mandatory to use everything from TS so don't stress it so hard 😁

Mahmoud Harmouch • Jan 10 '23

💯

Mihai Farcas • Jan 19 '23

Great article! Love the fact that you include the async versions.
Glad to see people interested in this topic!
I have a YT video on this same topic: youtube.com/watch?v=q1aNVIq3K7c
where I show some real world examples. Feedback is very appreciated!

Mwenedata Apotre • Jan 2 '23

I just knew pipe and now I know it differs to compose by just order of function execution! Thanks

Douglas Massolari • Jan 4 '23 • Edited

That's not always true, though.
In Elm, for example, pipe |> and composition >> have the same order of execution, the difference is that pipe is imediately executed while composition returns a new function:
Note: Everything after -- is a comment in Elm

add x y =
  x + y

sub y x =
  x - y

totalWithPipe =
  1
    |> add 10
    |> sub 5 -- 6

totalWithComposition =
  let
    calculateTotal =
      add 10 >> sub 5 -- returns a function
  in
  calculateTotal 1 -- 6

Not only in Elm, but pipe in fp-ts also works this way:

import { pipe } from 'fp-ts/function'

const len = (s: string): number => s.length
const double = (n: number): number => n * 2

// without pipe
assert.strictEqual(double(len('aaa')), 6)

// with pipe
assert.strictEqual(pipe('aaa', len, double), 6)

JoelBonetR 🥇 • Jan 4 '23

That's why the post has the tag #javascript 😁, either way love the insight! I haven't coded in Elm in ages, actually a good one, absolutely love the no runtime errors 🤩

It's sad that it got relatively few support...

Douglas Massolari • Jan 4 '23

Yes, but even in Javascript this concept can be different as you can see in fp-ts’ pipe.

I love coding in Elm! It is my first option when creating a Frontend.

From what I see, it seems some companies are adopting it, so, it seems it’s growing

JoelBonetR 🥇 • Jan 5 '23 • Edited

I picked the mathematical explanation for function composition:

In abstract algebra, a composite function is a function formed by the composition or successive application of more than one function. To do this, the function closest to the argument is applied to the argument, and the next function is applied to the result of the previous calculation.

in which case, this will fit in the description:

compose(function3, function2, function1)(initialArg);

The implementation details or nuances in Elm (or any other) is a different matter of discussion 😁

BTW glad to hear Elm it's getting a bit more love!

Douglas Massolari • Jan 5 '23

You are right.
But the point of my comment is pipe.
This is the one that have different implementations.
I just highlighted that the affirmation “pipe is the same as composition but reversed” is not always true

JoelBonetR 🥇 • Jan 5 '23

oh! understood now 😁 my bad

JoelBonetR 🥇 • Jan 2 '23

Anytime 😁

Gohomewho • Jan 5 '23

WoW this is so cool!

In the last example, I think the pipe from pipe(square, sum)([3, 5]); should be compose.

JoelBonetR 🥇 • Jan 5 '23

Hi Gohomewho, thanks for pointing it out! I'm fixing it right now 🙂

Ed Link III • Jan 3 '23

IMHO, the "ugly way" is a lot more intuitive and easier to read. Not that I don't appreciate the work you've done or the insight I gained from reading your article. ✌🏻

JoelBonetR 🥇 • Jan 4 '23 • Edited

It's your opinion and when you use it in your projects, it will be your code, so use the style you prefer or feel more comfortable with, it's totally OK! 😁

Edit: I wrote the post in different days (one bit at a time) and just realized I had been using different wording for the references on those functions

So for this one:

const pipe = (...functions) => 
  (initialArg) => {
    return functions.reduce((currentValue, currentFunction) => {
      return currentFunction(currentValue);
    }, initialArg);
  };

we could save few keyboard clicks by coding it like this:

const pipe = (...functions) => (initialArg) => 
  functions.reduce((currentValue, currentFunction) => {
      return currentFunction(currentValue);
    }, initialArg);

Just like this in the last one:

export const pipeAsync: any =
  (...fns: Promise<Function>[]) =>
  (initialArg: any) =>
    fns.reduce((currentFunc: Promise<Function>, func: Function | Promise<Function> | any) => currentFunc.then(func), Promise.resolve(initialArg));

Which is probably more... understandable?

Let me know, if it helps I can update the post! 😁

John Peters • Jan 3 '23

Nice Joel, thanks 😊

JoelBonetR 🥇 • Jan 3 '23

Thank you for reading John! 😉

John • Jan 4 '23

Can someone give a few examples of where this might be useful in the real world? :)

JoelBonetR 🥇 • Jan 4 '23 • Edited

Sure!
If you apply good practices and split the code in single-responsibility functions you'll end up chaining quite a few of them.

In OOP you'll do something like:

function replaceBy  (target, replacement) {
  return num.toString().split(target).join(replacement)
}

Whereas in functional programming it will look something like:

const replaceBy = (target, replacement) =>
  pipe(toString, split, join)([target, replacement);

Which is objectively better than

const replaceBy = (target, replacement) =>
  toString(split(join(target, replacement)));

Specially as the chain grows and for readability: you can actually read them from left to right in comma separated names, plus having just one initial arg usually helps to avoid side-effects.

So it's not a niche concept but a generic one, a nice to have (and use).

That's a bit of a silly example but it may work just to showcase, also you can find another example in the post 🙂

alessioferrine • Jan 4 '23

It's quite interesting things, thanks for writing about it

fruntend • Jan 9 '23

Сongratulations 🥳! Your article hit the top posts for the week - dev.to/fruntend/top-10-posts-for-f...
Keep it up 👍

Winsay vasva • Jan 6 '23

good article

JoelBonetR 🥇 • Jan 6 '23

Thank you Winsay 😁

Anna Baker • Jan 5 '23

Great Post!

JoelBonetR 🥇 • Jan 5 '23

Thank you Anna! 🙂

Luiyit Hernandez • Jan 5 '23

Very interesting, I also learned about curried functions. Thanks for sharing!

Naofumi • Jan 4 '23

I like this🔥

flyingCrp • Jan 5 '23

yeah,
just need one package, caolan.github.io/async/v3/docs.htm...
In the magical world of JS,If one package cannot be solved, find another package

JoelBonetR 🥇 • Jan 5 '23

Why to add a dependency to the project for something that takes less than 5 LoC?

flyingCrp • Jan 12 '23

I believe the power of the community is greater than the individual And different developers have different abilities

JoelBonetR 🥇 • Jan 12 '23 • Edited

But is the individual the one that would need to solve dependency compatibility issues, so choose wisely which ones are you going to import, because the less you add the more ease you'll be granted with during the maintenance of the project and further developments.

flyingCrp • Jan 13 '23

Yes, in the end, individuals are always dealing with these problems.

Rense Bakker • Jan 2 '23

Nice explanation and code examples. I still think you should ditch jsdoc though 😜 that said... Array reducers are the only time I dislike typescript... It always produces a type collision between the initial value for the reducer and the current value, so you always have to give the initial value an explicit type, instead of relying on type inference, which I prefer, because having to make changes in explicit typing (when they aren't for data models) sucks imho. Not sure if it would be technically possible for typescript to infer the type from the return value of the reducer function though... Probably not.

JoelBonetR 🥇 • Jan 2 '23 • Edited

Hahaha I prefer TS unless it's a quick script tbh, but IRL there are so many projects without TS that I feel like necessary to spread a bit of JSDoc (it makes it a lot easier to migrate JS to TS).

Type inference would be possible I guess but when you have functions that return different types then it will be a mess, I can imagine something like:

const userAge = getUserAge(); // inferred number
pipe( calcYearsBeforeRetirement, generateEmailBody, otherFunc )(userAge)

userAge is a number, then you calc the amount of years he needs to work before he can retire, which can also be a number, everything OK here, then you cast this number as string inside the email body so the return type is not a number anymore but a string, and so on and so forth.

Hence I assume that even if TS tried, most of the time it could be wrong idk 😅

Comment deleted

daniilGrebenick • Jan 6 '23

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