Disable the no-nested-ternary rule

[leroykorterink]

There is a proposal to disable the no-nested-ternary rule.

no-nested-ternary: introduces unnecessary verbosity
- @edgardz

Please see the documentation

[leroykorterink]

Nesting ternary expressions can make code more difficult to understand.

Incorrect code:

const foo = bar ? baz : qux === quxx ? bing : bam;

Correct code:

let thing;

if (foo) {
  thing = bar;
} else if (baz === qux) {
  thing = quxx;
} else {
  thing = foobar;
}

It's fine to use a eslint-disable comment if it does make code more readable, but that's most often not the case.

[ThaNarie]

When going multiline, the indenting helps to make it a bit more clear:

const foo = bar
  ? baz
    ? bing.foo.bar.baz
    : bam
  : qux === quxx
  ? bing.foo.bar.baz
    ? bing.foo.bar.baz
    : bam
  : bam;

If there was an option to force multiline for nested ternary, then I might be okay with it.

But even Leroy's example is not super readable on multiline (I would have preferred the last two lines to be indented as well):

const foo = bar
  ? baz
  : qux === quxx
  ? bing
  : bam.veryLongWordThatShouldBeSplitIntoMultipleLinesToAvoidHorizontalScrolling;

---

introduces unnecessary verbosity

In this case, that verbosity comes with clarity, which in my opinion is worth it.

Personally i've ran into this rule as well, but I'm happy it protects me against my own laziness :) Or in the rare occasion that it's okay to have it, I'll disable it.

[edgardz]

Some times we do conditional rendering inside components like:

export const Component = forwardRef<HTMLElement>(() => {
  const someConditionA = true
  const someConditionB = false
  
  return someConditionA 
    ? someConditionB 
      ? <div>condition b is true</div>
      : <div>condition b is false</div>
    : null
})

We could try to fix it by:

export const Component = forwardRef<HTMLElement>(() => {
  const someConditionA = true
  const someConditionB = false

  if (someConditionA) {
    if (someConditionB) {
      return <div>condition b is true</div>
    } else {
      return <div>condition b is false</div>
    }
  }
  return null
})

But the linter will complain again, now saying we SHOULD use a ternary:

export const Component = forwardRef<HTMLElement>(() => {
  const someConditionA = true
  const someConditionB = false

  if (someConditionA) {
    return someConditionB ? <div>condition b is true</div> : <div>condition b is false</div>;
  }
  return null
})

Personally, I don't like having multiple return functions in my components.
Not to mention the whole process of fighting with the linter is very frustrating and breaks the development flow.

[ThaNarie]

I probably would have written it like this in that case, when it has a clear exit conditions (data not available, still in loading state, etc).

export function Component() {
  const someConditionA = true;
  const someConditionB = false;

  if (!someConditionA) {
    return null;
  }
  
  return someConditionB  ? <div>condition b is true</div> : <div>condition b is false</div>;
}

But as said above earlier, i'm not heavily invested in this one.

---

Personally, I don't like having multiple return functions in my components.

That's worth a whole different discussion I'm afraid :D