Original

const pickBgColor = (colorName: string) =>
  colorName === 'active'
    ? colorName === 'active'
      ? 'var(--blue2)'
      : colorName === 'inactive'
    : colorName === 'inactive'
    ? 'var(--blue1)'
    : colorName === 'success' || colorName === 'abc'
    ? colorName === 'abc'
      ? 'var(--blue2)'
      : 'var(--blue23)'
    : 'var(--red4)';

const message = (i: number) =>
  i % 3 === 0 && i % 5 === 0
    ? 'fizzbuzzfizzbuzzfizzbuzzfizzbuzz'
    : i % 3 === 0
    ? i % 3 === 0
      ? 'ffizzbuzzfizzbuzzfizzbuzzfizzbuzzizz'
      : i % 5 === 0
    : i % 5 === 0
    ? 'fizzbuzzfizzbuzzfizzbuzzfizzbuzz'
    : String(i);

Current RP

const pickBgColor = (colorName: string) =>
  colorName === "active"
    ? colorName === "active"
      ? "var(--blue2)"
      : colorName === "inactive"
    : colorName === "inactive"
      ? "var(--blue1)"
      : colorName === "success" || colorName === "abc"
        ? colorName === "abc"
          ? "var(--blue2)"
          : "var(--blue23)"
        : "var(--red4)";

const message = (i: number) =>
  i % 3 === 0 && i % 5 === 0
    ? "fizzbuzzfizzbuzzfizzbuzzfizzbuzz"
    : i % 3 === 0
      ? i % 3 === 0
        ? "ffizzbuzzfizzbuzzfizzbuzzfizzbuzzizz"
        : i % 5 === 0
      : i % 5 === 0
        ? "fizzbuzzfizzbuzzfizzbuzzfizzbuzz"
        : String(i);

This is a good change as the tree of conditions is visible. It is easier to navigate and refactor using it (for example, move too large branches into separate variables to simplify the logic).

How about keeping nested ternaries flat (like now) only if all the nesting happens in the else-branches?

So it'd be either a tree or a fully flat chain, but never a semi-flat uh... thing like it happens now sometimes.

This was proposed earlier in #5258.

@thorn0 as I said in original issue, it will create noise in falsy branch when you add or remove in truthy branch.

@troglotit But how often is that going to happen? Not too often, isn't it? So this might be a good enough trade-off.

@thorn0 yeah... but the idea of alternating styles based on an arbitrary "looks good" is what irks me here.

I think it's best to keep this PR a straight up-and-down, one-line revert to previous behavior.

It can't remain a one-liner. If only because turning TS conditional chains into pyramids is not an option. As you already know, the current formatting for TS conditionals gets its share of criticism, but those complaints have nothing to do with "bring the indentation back".

We are close to v3 release, @rattrayalex want push this forward? Personally, I'm 👍 for this change.

Yeah I really do. I've just been blocked on writing an extensive PR description / blog post justifying the change, and any merge conflicts or corner case bugs that may be lurking.

I'd love help getting it over the line!

I might be able to devote some time to it this weekend...

(thanks for the words of support btw)

@fisker (and/or @thorn0 if you're around) would you mind taking a look at #13183 instead, which supersedes this?

Wait for @fisker review before merging

My support goes 100% to this, and 0% to #13183 😄

gentle bump @fisker (this is blocked on you, and you'd previously given it a thumbs-up)

Unbelievable! It's been 3 years! It finally merged!

At least, we finally have this, until it gets superseded by #13183 (which will probably happen, whether we like it or not).

Regardless, thank you so much for the merge. This should have been there in the first place.