Risky question to be opinionated. I'm working on a project with Ramda.js. And I see many ifElse calls throughout the code.

const getEvent = R.ifElse(
  fireable,
  R.always(sendAnalyticsEvent),
  R.always(R.always(undefined))
);

Is this really worth the effort to wrap logic in a functional conditional like this? Is there a benefit?

If ultimately Ramda just abstracts a ternary operation and we return undefined on false match.

Ramdas ifElse

var ifElse = _curry3(function ifElse(condition, onTrue, onFalse) {
  return curryN(Math.max(condition.length, onTrue.length, onFalse.length),
    function _ifElse() {
      return condition.apply(this, arguments) ? onTrue.apply(this, arguments) : onFalse.apply(this, arguments);
    }
  );
});
export default ifElse;

This seems like an anitpattern in the FP world, always returning undefined or in some cases null

R.ifElse(hasUrl, promptToShare, R.always(null))

Regardless of the questionable return of undefined, wouldn't using ternary operators be more idiomatic to a javascript munity?

hasUrl(urlObject) ? promptToShare() : null

This seems more succinct and legible to me, I want to refactor. But this could be due to my naivety of the FP world.

Risky question to be opinionated. I'm working on a project with Ramda.js. And I see many ifElse calls throughout the code.

const getEvent = R.ifElse(
  fireable,
  R.always(sendAnalyticsEvent),
  R.always(R.always(undefined))
);

Is this really worth the effort to wrap logic in a functional conditional like this? Is there a benefit?

If ultimately Ramda just abstracts a ternary operation and we return undefined on false match.

Ramdas ifElse

var ifElse = _curry3(function ifElse(condition, onTrue, onFalse) {
  return curryN(Math.max(condition.length, onTrue.length, onFalse.length),
    function _ifElse() {
      return condition.apply(this, arguments) ? onTrue.apply(this, arguments) : onFalse.apply(this, arguments);
    }
  );
});
export default ifElse;

This seems like an anitpattern in the FP world, always returning undefined or in some cases null

R.ifElse(hasUrl, promptToShare, R.always(null))

Regardless of the questionable return of undefined, wouldn't using ternary operators be more idiomatic to a javascript munity?

hasUrl(urlObject) ? promptToShare() : null

This seems more succinct and legible to me, I want to refactor. But this could be due to my naivety of the FP world.

• javascript
• functional-programming
• ternary-operator
• ramda.js

• 2 You can partially apply/curry a function. You cannot partially apply operators in JS. – zerkms Commented Sep 19, 2018 at 3:06
• 1 You also can't pose them. – Jared Smith Commented Sep 19, 2018 at 20:45

1 Answer 1

Several points (disclaimer: I'm a Ramda author):

• Far too often, you're right. Point-free code is overused when new users pick up FP in Javascript. I generally suggest that it's only useful when it improves readability.

• An ifElse invocation is not equivalent to a Javascript conditional expression (ternary.) It can be equivalent to a lambda function that returns the value of a ternary, however. That is, the example would be more like (urlObject) => hasUrl(urlObject) ? promptToShare(urlObject) : null. At this point, the ifElse is at least possibly more readable. This brings us to the points from the ments about partial application/currying

• There is little reason I can see to use ifElse with functions that have different signatures. That is, if promptToShare takes no arguments, then it probably doesn't belong in a call to ifElse.

• That getEvent function looks quite bizarre. Given that it uses a name like sendAnalyticsEvent, I'm guessing that it creates some side-effect. And the other branch is a no-op. While the Ramda team doesn't really care how you use the library, this is not the sort of function we envision users creating with it.

• I've seen other odd calls to ifElse passing identity for one of the branch functions. Those should presumably be replaced with when or unless, which would certainly be more semantic.

So I agree that your example does not need ifElse at all. But ifElse and its peers when and unless do have their places.