this is all fun and games until prettier turns it into an absolute mess.
Show HN: A JavaScript function that looks and behaves like a pipe operator
121–130 of 148 posts
Re: Show HN: A JavaScript function that looks and behaves like a pipe operator
#12290% of the time a little weed enhances coding productivity and solution clarity, the other 10% however…
Re: Show HN: A JavaScript function that looks and behaves like a pipe operator
#123Earlier quoted context omitted.
What if it isn't a message? What if "msg" is already used for another variable?
`greetingMsg`? `greeting`? Naming the other one differently? Splitting the work done with that message and the work done with this message into their own functions?
Frankly, this always sounded like a readability issue seeking a readability problem. Splitting because the names clash, because you decided to name things, because a one-liner was less than ideally readable.
Re: Show HN: A JavaScript function that looks and behaves like a pipe operator
#124I think what makes a programming language easy to use is largely due to the constraints that it imposes, through carefully thought-out design decisions.
At first the constraints may be difficult to grasp. You may feel like a feature is missing, but that's part of learning a language. Once you have learned them, the constraints actually become helpful.
One thing I dislike about JS is that it's like the wild west. You have a mash-up of all different paradigms that are possible, so you get libraries like this. No, I wouldn't say this makes code more readable, though I'm a fan of the pipe in other languages. It just makes yet another way to do the same thing.
I don't mean to be rude or ranty, so with that said, it's cool that you were able to make this. Kudos for that.
Re: Show HN: A JavaScript function that looks and behaves like a pipe operator
#125I use ppipe: https://github.com/egeozcan/ppipe Looks tidier to my eyes const newPipe = ppipe.extend({ divide (x, y) { return x / y; }, log(...params) { console.log(...params); return params[params.length - 1]; } }); const res = await newPipe(10) .pipe(x => x + 1) .divide(_, 11) .log("here is our x: ") //logs "here is our x: 1" .pipe(x => x + 1) // 2
But then you have to define each method in advance, it doesn’t look like the pipeline operator at all, but more like the old jQuery.fn.method shenanigans.
That's not the case at all, have a look at the docs. The thing is pretty powerful.
Re: Show HN: A JavaScript function that looks and behaves like a pipe operator
#126Earlier quoted context omitted.
The strength of the pipeline operators comes when you have to do method chaining things like: const foo = capitalize(underline(reverse(exclaim(indent(value))))); I already forgot the amount of parentheses I needed to close with while typing that.
value.indent() .exclaim() .reverse() .underline() .capitalize() There’s always the OOP version of method chaining!
Which is great until Prettier, in its infinite wisdom, decides it's better to stick four of these function invocations on one line and two on the next, so you have an obnoxious mishmash of tokens!
Re: Show HN: A JavaScript function that looks and behaves like a pipe operator
#127Just looked at the examples. To me every one of them makes the original code less readable. I would also encourage people to not get used to this style because now you are stuck on some weird JS style and will have trouble reading code in other languages.
Re: Show HN: A JavaScript function that looks and behaves like a pipe operator
#128I think what makes a programming language easy to use is largely due to the constraints that it imposes, through carefully thought-out design decisions. At first the constraints may be difficult to grasp. You may feel like a feature is missing, but that's part of learning a language. Once you have learned them, the constraints actually become helpful. One thing I dislike about JS is that it's like the wild west. You…
> I think what makes a programming language easy to use is largely due to the constraints that it imposes, through carefully thought-out design decisions.
That's interesting. I'm pretty well convinced of the opposite. I primarily work with Ruby, which doesn't really have a whole lot of language constraints in the context of "what can I do?". Part of the language design philosophy of Ruby is to give developers "sharp knives" and let them individually avoid chopping off their own fingers. I haven't tried my self but I would expect that something similar or identical to this could be implemented in Ruby and I wouldn't consider that to be something which makes it worse. Indeed, that's one of my favorite features of the language.
Re: Show HN: A JavaScript function that looks and behaves like a pipe operator
#129Earlier quoted context omitted.
value.indent() .exclaim() .reverse() .underline() .capitalize() There’s always the OOP version of method chaining!
Which is great until Prettier, in its infinite wisdom, decides it's better to stick four of these function invocations on one line and two on the next, so you have an obnoxious mishmash of tokens!
Which is a problem of Prettier. I wish for the day that someone builds rustfmt but for Typescript, I will happily leave Prettier and StandardJS behind.
I think it could be done today with a (big) number of ESLint plugins.
Re: Show HN: A JavaScript function that looks and behaves like a pipe operator
#130>The following example code is a bit hard to read: >const { status } = await send(capitalize(greeting) + "!") >console.log(status) No it's not hard to read. >Make it less nested, more vertical, by using the V "pipe": >V( greeting, // initial value "hi" >V (capitalize), // custom function call "Hi" >V .concat("!"), // String method `concat` call "Hi!" >V (send), // custom async function call Promise { } >V .status, //…
[deleted]