jsx-indent rule with ternary operators on multiple lines and JSX elements

[goffreder]

This code

const foo = bar
    ? (
        <p>
            {'Bar is true!'}
        </p>
    )
    : (
        <p>
            {'Bar is false!'}
        </p>
    );

violates the jsx-indent rule on the lines with the <p> opening tags, saying that everything should be brought one level back.

I use a lot this syntax, especially when I have to render one complex component or another according to a boolean variable, and I can't seem to find a workaround to avoid the linting error (apart from not using the ternary operator, which I don't like).

[ljharb]

I think what it wants might be more like:

const foo = bar
  ? (<p>
        {'Bar is true!'}
    </p>)
  : (<p>
        {'Bar is false!'}
    </p>);

[goffreder]

Eugh, really? Those round brackets look awful...

Moreover, that is still invalid. This is the syntax my eslint is accepting (but maybe it's due to me using 4 spaces instead of 2 for indentation):

const foo = bar
    ? (<p>
        {'Bar is true!'}
    </p>)
    : (<p>
        {'Bar is false!'}
    </p>);

This becomes even uglier when I use self-closing tags and the jsx-closing-bracket-location rule:

const foo = bar
    ? (<div
        k={1}
       />)
    : (<div
        k={2}
       />);

But maybe there's no "right" way to indent those mixes of js and jsx...

[neverfox]

Yeah, that's not right. It should be keying off the opening tag, no matter the context:

Should be possible:

return canRender
  ? <Foo>
      className="foo"
    </Foo>
  : null

But both jsx-indent and jsx-indent-props complain about the props indentation and the closing tag indentation. Basically I think it's just checking the line the opening tag is on, and basing the indentation check on the first non-whitespace character rather than the <, as it should.

[straku]

I'm using syntax mentioned by @neverfox very often and it would be extremely useful if jsx-indent and jsx-indent-props rules worked correctly with it.

[bryce-larson]

I am also using something similar to @neverfox, would love to see support for the following for jsx-indent-props

Instead of

return colHidden
      ? <span
        className="hidden">
      </span>
      : <span
        className="shown"
        ref="myCol">
        <span>foo</span>
      </span>;

Should be

    return colHidden
      ? <span
          className="hidden">
        </span>
      : <span
          className="shown"
          ref="myCol">
          <span>foo</span>
        </span>;

[tuures]

there's also another related issue that also has to do with jsx-closing-bracket-location.

With:

"react/jsx-indent": [1, 2],
"react/jsx-indent-props": [1, 2],
"react/jsx-closing-bracket-location": [1, {selfClosing: "tag-aligned", nonEmpty: "tag-aligned"}],

I think this should be valid (with one prop):

<Layout head={
  <HeadContent/>
}> // error here, eslint does not allow the closing brace to be part of closing bracket when opening brace is part of opening bracket
  <MainContent/>
</Layout>

but eslint expects:

<Layout
  head={
    <HeadContent/>
  }
>
  <MainContent/>
</Layout>

[alex35mil]

I use it this way:

isSomething
? <SomeComponent />
: <AnotherComponent
    className={css.component}
    onSomething={props.doSomething}
  />

And it fails w/o:

/* eslint react/jsx-indent-props: 0, react/jsx-closing-bracket-location: 0 */

[tvervest]

I have to say I agree with the indenting as described by @goffreder. The ternary operator is indented by one level and the values are either a single line or contained within parenthesis where the content is indented (again) and the closing parenthesis is on the same level as the operator;

isSomething
  ? (
    <MyComponent>
      <WithAChild />
    </MyComponent>
  )
  : <SomethingElse>

To me it just feels the most natural as the operators are indented in a way that's similar to chained methods and the parenthesis indentation is similar to the indentation of curly brackets for control statements. The parenthesis are purely used to indicate scope for multi-lined elements and make it easier to determine where the current part of the operator ends. This is also why I think the brackets should close on the same indentation as the matching question mark or colon, as you can spot the next part of the ternary operator in a glance when reading the code. Obviously, if the element (or statement) is only a single line the parenthesis can be left out.

But that's just my humble opinion :)

[sompylasar]

Any update on this please?

[martin-cech]

Hello, +1 for supporting

condition
  ? <Foo>
      <Bar />
    </Foo>
  : <Baz />

if possible :-)

[sompylasar]

@yannickcr @ljharb Guys please share your thoughts on this issue?

[lencioni]

I am happy to help review a PR that improves this rule. It sounds like there are a few styles that folks desire, so it would be good if the rule could enforce each style with this rule, chosen via an option.

[straku]

This example:

(condition)
  ? <Comp
      foo={x}
      bar={y}
    >
      <ChildrenComponent />
    </Comp>
  : <AnotherComp />

breaks 3 rules: jsx-indent, jsx-indent-props and jsx-closing-bracket-location. @lencioni how would you like to enforce this and potentially other styles across all 3 rules? Wouldn't it be better to simply allow mentioned style in existing rules?