Show HN: A JavaScript function that looks and behaves like a pipe operator (github.com)

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

  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.

  The following example code is a bit hard to read:

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

  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
  )

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

    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

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

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

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

  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.

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.

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'''

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

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

  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

  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)