Cover image by arbyreed on Flickr. JavaScript is getting more and more functional programming features, an exiting one is the new pipeline operato...
For further actions, you may consider blocking this person and/or reporting abuse
For further actions, you may consider blocking this person and/or reporting abuse
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
pipefunction in RamdaJS. It's gonna be nice to have this natively.I guess it's the same as the
flowfunction in Lodash, isn't it? I always use it!RamdaJS is pretty awesome, yes.
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 |> ftoo.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?
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.