Show HN: A JavaScript function that looks and behaves like a pipe operator

  pipe((p) => ([
    "hello",
    p.concat("!"),
    send,
    p.status,
    console.log
  ]));

The pipe function would then iterate over the array, calling methods as described.

It's not immediately clear what should happen when a method's return type is a function, but I suppose this can be handled via convention.

  from functools import partial
  
  class Pipeable:
      def __init__(self, fn):
          self.fn = fn
  
      def __ror__(self, lhs):
          return self.fn(lhs)
  
  def pipeable(fn):
      return lambda *args: Pipeable(partial(fn, *args))
  
  filter = pipeable(filter)
  map = pipeable(map)
  list = pipeable(list)
  sum = pipeable(sum)
  min = pipeable(min)
  max = pipeable(max)
  any = pipeable(any)
  
  # Usage:
  
  range(1, 100) | filter(lambda x: x < 50) | max()
  # 49
  
  [1, 2, 3, 4] | filter(lambda x: x % 2 == 0) | map(lambda x: x * 3) | list()
  # [6, 12]
  
  [1, 2, 3, 4] | map(lambda x: x >= 5) | any()
  # False

    Object.prototype.pipeTo = function(f) {
      return f(this)
    };

  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 { <pending> }
      V.status,       // automatic promise chaining + getting property  Promise { 200 }
      V(console.log), // automatic promise chaining + global function call  logs 200
  )

  (-> x
     (f)
     (g)
     (h))

https://github.com/tc39/proposal-pipeline-operator

See Clojure macros for thread-first `->`, thread-last `->>`, thread-as `as->`, `some->`, `some->>` and `cond->`: https://clojure.org/guides/threading_macros

You can leave all this hurt behind you and use ClojureScript, which compiles to JavaScript.

    status = greeting+"!" ~> capitalize ~> send

1: ~> being a pipe operator

2: Calling an async function from within an async function implies await

Without 2, it would look like this:

    status = greeting+"!" ~> capitalize ~> await send

But please don't promote antipatterns from languages that actually have a pipe operator (like Elixir) such as the '''concat("!")''' where the previous implementation's version using an operator is much clearer and more idiomatic.

I see a ton of Elixir code where people shoe-horn things into a vertical pipeline where the "normal" code would be a lot more readable, for example invoking '''Kernel.+(2)''' instead of just doing '''my_var + 2'''

  greeting = capitalize(greeting);
  greeting = greeting.concat("!");
  greeting = await send(greeting);
  greeting = greeting.status;
  console.log(greeting);

It has a lot of interesting features that would be difficult to replicate in JavaScript.

[0] https://wiki.tcl-lang.org/page/pipethread

[1] http://www.rkeene.org/tmp/pipethread-presentation-withnotes....

  export const pipe = <A, B>(f: Fun<A, B>) => {
      return {
          to: <C>(g: Fun<B, C>) => pipe((arg: A) => g(f(arg))),
          build: () => f,
      };
  };

  const process = pipe(readLines).to(x => cut(x, 2)).to(....).build()

  const result = await process(fd)

    pipe([
      f, 
      g,
      h,
    ])(123);

Same thing. Less code, standard functions.

And then, remembering that everything has already been invented, I found this:

https://github.com/elixirscript/elixirscript

You're welcome.

[1] https://github.com/gcanti/fp-ts

  const { status } = await
    send(
      capitalize(greeting)
      + "!"
    )

  const message = capitalize(greeting) + "!"
  const { status } = await send(message)

With complex operations a pipe-method would make more sense.

But i will wait for the native pipeline-operator <https://github.com/tc39/proposal-pipeline-operator> instead using now a function.

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

  const { status } = await send(capitalize(greeting) + "!")
  console.log(status)

https://ramdajs.com/docs/#pipe

https://gcanti.github.io/fp-ts/modules/function.ts.html#pipe

https://www.npmjs.com/package/qtools-asynchronous-pipe-plus

V(greeting, capitalize, ['concat', "!"], send, 'status', console.log )

but at that point it's already Ramda or smt and doesn't look as funky

  >const { status } = await send(capitalize(greeting) + "!")
  >console.log(status)

  >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 { <pending> }
  >V .status,       // automatic promise chaining + getting property  Promise {200}
  >V (console.log), // automatic promise chaining + global function call  logs 200 )

  The following example code is a bit hard to read:

  const { status } = await send(capitalize(greeting) + "!")
  console.log(status)

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.