Breaking Chains with Pipelines in Modern JavaScript(wix.engineering)
wix.engineering
Breaking Chains with Pipelines in Modern JavaScript
https://www.wix.engineering/post/breaking-chains-with-pipelines-in-modern-javascript
7 comments
A simple example would be mixing map/reduce stuff on arrays with other non-built-in utility functions that take arrays without having to break the logical flow.
For a very simple example, manipulating and summing an array of values:
For a very simple example, manipulating and summing an array of values:
import { range, sum } from 'ramda';
range(0, 6)
|> x => x.map(i => i * i)
|> sum
Compare to: import { range, sum } from 'ramda';
sum(
range(0, 6)
.map(i => i * i)
)
...and then add three or four other non-builtin methods in between map steps and consider the resulting readability.I mean, I think one of the big arguments against a pipeline operator is that you can easily roll your own with
const pipe = (...fxs) => x => fxs.reduce((v, f) => f(v), x);
If you're going to pull in ramda for example, they have their own pipe, and a map function that takes (predicate, array) as curried arguments, to aid with composition
import { map, pipe, range, sum } from 'ramda'; pipe(
range,
map(i => i * i),
sum
)(0, 6)
I haven't messed with HN formatting before, so I hope that turns out right. My team uses Ramda and pipes regularly in our Node code, and its absolutely wonderfulI really wish we could just get a pipeline operator past stage 1. It seems like such a simple idea philosophically but apparently the big players can't agree on any of the exact details.
> Fortunately, a much better syntax for this type of expressions is being introduced by ECMAScript, known as the pipeline operator.
This is "Stage 1: Strawman Proposal." It's not exactly accurate to say the operator is being introduced "by ECMAScript", more like "it's being proposed for addition to the ECMAScript specification."
This is "Stage 1: Strawman Proposal." It's not exactly accurate to say the operator is being introduced "by ECMAScript", more like "it's being proposed for addition to the ECMAScript specification."
I would have preferred .pipe, .partial and .partialRight functions in the std library instead of adding more syntax sugar.
Since when does "modern" mean not-yet-standardized?
perhaps it should be called "post-modern"?
Huh, I'd never seen a pipe method with the # as the placeholder before. That seems like a pretty nice way to make it flexible.
Clojure has a similar thing, where % is used as a placeholder in threading, which is similar https://clojure.org/guides/threading_macros
Personally, I'd rather see it go through with no placeholder at all so it can just happen without people arguing over it forever, and then have a placeholder added in a future proposal.
RamdaJS may interest you if you like pipes
For anyone looking at picking up Ramda, the docs at ramdajs.com are great API docs, but don't tell you a thing about how to actually use lenses, transducers, and point free data last functions with pipes. Randy Coulman has a great list of guides on how to actually use Ramda on his blog[1]. Start at the bottom with the introduction and work your way up.
https://randycoulman.com/blog/categories/thinking-in-ramda/
https://randycoulman.com/blog/categories/thinking-in-ramda/
From a cognitive perspective, it doesn't make code more readable or easier to understand.
From a practical perspective, why? What can't we do with it that isn't aesthetic?
Edit: Okay, after reading through the article again, I get it. I've had issues with eager loading in Node AND I will say the pipeline is easier to understand than simply using generators. Good article.