Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

jsx-one-expression-per-line confusion #1855

Closed
lencioni opened this issue Jun 26, 2018 · 3 comments
Closed

jsx-one-expression-per-line confusion #1855

lencioni opened this issue Jun 26, 2018 · 3 comments

Comments

@lencioni
Copy link
Collaborator

I'm finding this documentation to be a little confusing: https://github.com/yannickcr/eslint-plugin-react/blob/master/docs/rules/jsx-one-expression-per-line.md

Specifically, examples in both the invalid and valid sections are actually just invalid JSX. Here's one example from both the invalid and valid sections:

<App>
  </Hello> World
</App>
<App>
  </Hello>
  World
</App>

Should this be <Hello /> instead?

Also, the examples and test cases leave a lot of things out. For instance, what about this code:

<App>Hello</App>

How will this rule treat this code? Or something a little more complex:

<App>{foo} - {bar}</App>

This seems to get autofixed in a way that removes meaningful whitespace, which seems like a bug. I thought about putting up a failing test case for this, but after looking at the documentation for the rule, I'm not really sure I understand the scope and purpose of it.

@ryansully
Copy link

For something like

<App>{foo} - {bar}</App>

I'd probably use a template literal to preserve whitespace:

<App>
  {`${foo} - ${bar}`}
</App>

Not exactly an improvement though, and makes the code harder to understand.

In other places I add {' '} if I need whitespace that won't be eaten by React, though that's more of a flaw/feature of React itself than of this ESLint plugin.

@ljharb
Copy link
Member

ljharb commented Jul 6, 2018

I believe #1848 will cover this.

@ljharb
Copy link
Member

ljharb commented Feb 6, 2022

Closing in favor of #1848.

@ljharb ljharb closed this as completed Feb 6, 2022
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Development

No branches or pull requests

3 participants