About no-nested-ternary

I sometimes use the following syntax that I find elegant and useful. What do you think about it? And What do you suggest to replace it?

var foo =
  condition1 ? a :
  condition2 ? b :
  condition3 ? c :
  d;

[rsp]

@ggomesfe In your example above:

var foo = d;
if (condition1) {
    foo = a;
} else if (condition2) {
    foo = b;
} else if (condition3) {
    foo = c;
}

we need to have useless mutation and cannot use const that we could use in:

const foo =
  condition1 ? a :
  condition2 ? b :
  condition3 ? c :
  d;

which have semantic consequences that are beyond mere style - i.e. the variable is no longer protected from being reassigned - an otherwise promoted property in the spirit of prefer-const rule described in https://github.com/airbnb/javascript#variables

To use your example to assign to a const we would need to either use a closure:

const foo = (() => {
  if (condition1) {
    return a;
  } else if (condition2) {
    return b;
  } else if (condition3) {
    return c;
  } else {
    return d;
  }
})();

or use a temporary variable:

let fooTemp = d;
if (condition1) {
  fooTemp = a;
} else if (condition2) {
  fooTemp = b;
} else if (condition3) {
  fooTemp = c;
}
const foo = fooTemp;

Both of those workarounds seem to be much less clear than the use of the ternary operator for what it was designed for.

[rsp]

@testerez Your last example is what I like the most. In fact, multiline ternary is what I find much more readable than the if/elses - it’s short, readable, to the point, always evaluates to a single expression, has a very functional programming feel.

In fact, looking at the two examples in your post I find it surprising that the Airbnb style guide which is otherwise very functional-programming-oriented forces me to change the second one to the first one. If anything I would expect it to work the other way around - to recommend the ternary operator if all you have in the if/else blocks are returns.

I would understand if it didn’t allow the ternary operator at all but saying that this is readable:

const a = x =>
  x < 2 ? 2 :
  x;

and this is not:

const b = x =>
  x < 2 ? 2 :
  x < 3 ? 1 :
  x;

seems strange to me, especially when compared to the recommended style:

const c = (x) => {
  if (x < 2) {
    return 2;
  } else if (x < 3) {
    return 1;
  }
  return x;
};

I’d like the linter to tell me that I can simplify the last example with a ternary operator, not that I shouldn’t use the ternary operator at all (unless it’s for a single comparison - in which case it’s fine). Unfortunately the linter doesn’t share my view on this.

@ljharb I agree that clarity is far more important than brevity - I just don’t think that function c() above is more clear that function b(). This is the only issue that I have with those linter rules so far after using them extensively in production for large Node projects for over a year so don’t get me wrong. I think you’ve done an amazing job, many thanks for that. Now, if you just stopped hating my favorite operator it would be perfect. 😉