Cover image by arbyreed on Flickr.
JavaScript is getting more and more functional programming features, an exiting one is the new pipeline operator.
The operator is stage-1
so it won't be included in the standard right away, but you can already use it with the help of babel.
Why
If you come from an object oriented background, you probably used the dot operator quite alot. Many libraries use it to implement small DSLs, often called fluent interfaces, that help you to get things done with good readability.
For example Moment.js
moment().add(2, "days").substract(10, "hours").toString();
An functional alternative is date-fns/fp, but as you can see, the nested function calls make it a bit hard to read.
format("D MMMM YYYY", subHours(10, addDays(2, new Date())));
Now wouldn't it be nice, to have this kind of left-to-right readability for functional code too?
What
This is where the new piping operator comes in handy, it allows you to make this kind of code more readable.
f(10);
becomes
10 |> f;
So the date-fns/fp
example from above becomes
const add2Days = addDays(2);
const sub10Hours = subHours(10);
const customFormat = format("D MMMM YYYY");
new Date() |> add2Days |> sub10Hours |> customFormat;
or in short:
new Date()
|> addDays(2)
|> subHours(10)
|> format("D MMMM YYYY");
As you can see, the operator requires a function that only needs one argument. The date-fns/fp
functions return such functions, when only called with one argument.
This also works with asynchronous functions, because they are build on top of promises, which return one result.
"USERID_123"
|> await loadUserFromApi // async
|> extractUserImageUrl // sync
|> await cropUserImage; // async
Conclusion
Again, JavaScript takes a step into the FP direction and build on top of the additions it already had. Especially server-side data-transformation code will profit from code written this way.
Top comments (15)
As an avid Elixir user this couldn’t make me happier!
Coming from the "old world", it looks a bit weird at first :)
Looking at
|> addDays(2)
, I would expectaddDays(2)
to be evaluated before being used as a function. In my mind, this can only work ifaddDays(2)
actually returns a function.> In my mind, this can only work if addDays(2) actually returns a function.
This is what it does :)
A regular version of that function would look like that:
A curried version looks like that:
As I didn't come around to try this yet, I have one question.
Does the pipe operator know where to put the output of the previous function as input on the next one?
I am asking because:
Takes the value as the second param.
though takes the value as the first param.
Overall I think it's awesome that this comes to JS.
And a thank you for the posts you are putting out. Always looking forward to them.
I think I wrote it wrong. It always uses the first argument. fixed it.
I enjoy the
pipe
function in RamdaJS. It's gonna be nice to have this natively.I guess it's the same as the
flow
function in Lodash, isn't it? I always use it!RamdaJS is pretty awesome, yes.
I love it, and truly believe this is one small (big) step to popularize FP. Can be retrofitted with a
pipe()
fn (hint RamdaJS) for those who dislike the operator (for now!). Cool summary.So, is this only syntactic sugar? I personally don't see any increase in readability when I compare
|> something()
to.something()
.Yes.
You could see it as the FP equivalent to the dot operator of OOP.
v |> f
too.m()
Do you really prefer
function1(function2(function3(function4(param))))
?Why? It's a common and very much enjoyed operator in multiple other FP languages.
Could you elaborate?