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-prefer-fragment-wrappers: Allow for being less strict #316

Open
binary64 opened this issue Jan 20, 2022 · 0 comments
Open

jsx-prefer-fragment-wrappers: Allow for being less strict #316

binary64 opened this issue Jan 20, 2022 · 0 comments

Comments

@binary64
Copy link

Overview

I wish to ban the code as exactly specified in the jsx-prefer-fragment-wrappers docs page. So I added the rule to my eslintrc, which I was happy to see complain about the following scenario:

  // Scenario 1 - THIS ERRORS - very good, I really want this rule
  return (
    <div>
      <p>hi</p>
      <p>hi</p>
    </div>
  )

However, there are 2 more scenarios which are much more strict that the original rule suggests it would be:

  // Scenario 2 - THIS ERRORS - a little strict, but I like this
  return (
    <div>
      <span>hi</span>
    </div>
  )

  // Scenario 3 - THIS ERRORS - damn, this isnt good because we need code like this
  return (
    <div>
      <div>
        <p>hi</p>
      </div>
      <p>hi</p>
      <p>hi</p>
    </div>
  )

Motivation

Scenario 1 is purely as described in the documentation. I love it.

Scenario 2: I like the above rule because the

could easily do the with pure CSS.

Scanerio 3: I dislike the above because often you will need the above html tree. I do agree that ideally, this rule would be active for the cleanest codebase, but our codebase isn't clean enough to be this pure.

However, the point of this ticket is to ask for an option where we can opt-out of Scenario 2 and 3, because they are objectively stricter than Scenario 1.

Scope/Area

I can't add labels but the rule name is @shopify/jsx-prefer-fragment-wrappers.

I didn't put this as a Feature Request because I cheekily assert that Scenario 2 and 3 are "false" positives that are also useful to have (but optionnally).

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant