Tap does not execute the provided function if it receives no arguments

[kallja]

The function created by calling R.tap does not execute if arguments are not provided.

See the provided example.

const tap = R.tap(() => { console.log('some debug logging'); });

// Executes `logSomething`
tap(undefined);

// Does not execute `logSomething`
tap();

[adispring]

Because most ramda's functions are auto curried, in ramda's curry mechanism:

1. tap() receiving zero argument, and just return the tap itself, tap() == tap
2. tap(undefined) receiving one argument, and execute tap's body.

For example, this is what ramda's inner function _curry1 (one of ramda's basic inner curry function) do :

export default function _curry1(fn) {
  return function f1(a) {
    if (arguments.length === 0 || _isPlaceholder(a)) {
      return f1;
    } else {
      return fn.apply(this, arguments);
    }
  };
}

as you can see,

_curry1(console.log)() // just do nothing but returned console.log
_curry1(console.log)(undefined)  // output 'undefined'

So, in your example, tap is a ramda style curried function,tap()(undefined) execute as tap(undefined) do, and tap() just approximately return itself.

[CrossEye]

The only use I've ever had for tap is to log something in the middle of a pipeline:

const foo = pipe (
    doSomething,
    doSomethingElse,
    tap (console.log),
    weNowReturnYouToYourRegularlyScheduledPipeline,
    doOneMoreThing
)

And in such circumstances, of course, the pipeline must be supplying data, so one would never notice that tap (fn) () doesn't actually do something.

Of course @adispring's analysis of why this is so is spot-on. @buzzdecafe has long argued that curry1 is superfluous, that we should throw if no data is supplied. Thankfully for just as long, cooler heads have prevailed. 😉. In any case, this is not something I see changing soon.

[kallja]

The only use I've ever had for tap is to log something in the middle of a pipeline

Unless of course the data comes into your pipeline as a part of a more complex process and you're logging your input as the very first step of the Ramda pipeline, which was the case where I noticed this happening.

As addressing this would probably need unfortunate tradeoffs in other areas (change currying) and as this is pretty much an edge case, it's probably not worth acting upon in any way. It's just good to know that not seeing an expected log message might be caused by this.

[CrossEye]

@adispring: Could you get in touch with me at some point? I'd like to ask you something in a quieter forum. I'm scott@sauyet.com and @scott_sauyet on Twitter.