[New] add jsx-no-useless-fragment rule

[golopot]

fixes #2042

This rule disallows fragments with less than 2 children.

[ljharb]

Should this rule be autofixable?

[golopot]

Autofixing <>foo</>, <>{foo}</> might break people's code if they use PropTypes.element, or uses some type checker.

Case like <><Foo /></> looks ok to be autofixable.

[ljharb]

hm, maybe if there's cases that aren't safe to autofix, those should be separately controllable by an option?

[golopot]

Now fragments in html element are reported.

Example:

<section>
  <>
    <div />
    <div />
  </>
</section>

[ljharb]

So any time a fragment is being passed to an HTML element, it should be autofixable to inline the fragment's children, no?

[golopot]

Now a fragment is fixable if it is not an outermost element, except for when it might add extra spaces. The fix is a simple removal of openingElement and closingElement.

// fixing by simply removing fragments will add a space between "git" and "hub"
<div>
  git<>
    hub
  </>
</div>

[ljharb]

Couldn't that be fixed into:

<div>
  git{`
    hub
  `}
</div>

or

<div>
  git{' hub '}
</div>

?

[golopot]

I think it is ok to leave these cases without a fix. Your fixed code both render "git hub", but my code renders "github".

[ljharb]

ah, git{'hub'} or just github then? but sure, leaving it without a fix is fine too.

[captbaritone]

Hey! I'm curious what the status of this PR is. I just wrote a similar rule myself before I saw this PR.

If you plan on coming back and getting this across the finish line, I'll just add one more thing to consider: Fragments can be given props. Specifically key.

If you don't plan on coming back to this, I'd be happy to open a PR with the one I've written once we having it running for a little while and I'm confident there are no major issues.

[ljharb]

@captbaritone please don't open a second PR; it'd be better to update this one.

[ljharb]

Seems like we need to also add prose and examples and tests showing that a fragment is not useless if it has a key prop and also appears in a context where a key prop makes sense (ie, inside an array literal or returned from a function)

[golopot]

I pushed a version just let pass any keyed fragment.

[captbaritone]

If a fragment has only a single JSXElement child, it is still useless even if it does have a key.

For example:

<React.Fragment key={someVar}>
  <div />
</React.Fragment>

Should be refactored/fixed to:

<div key={someVar} />

[ljharb]

That's not entirely true; something might be cloning the element.

[captbaritone]

Another case which is worth considering:

<>
  In a case like this, fragments offer a nice way to split long
  strings across multiple lines. Using a fragment here, while
  technically useless, is probably nicer than using a quoted
  string.
</>

[ljharb]

@captbaritone given that you can use backticks for the same effect, it seems like using a fragment there is strictly worse than the alternative (making an object instead of a string literal)

[captbaritone]

@ljharb from a technical/performance perspective, I think you’re right, but from a readability/developer experience, perspective I think there’s a reasonable argument for fragments. With back ticks, new lines and indentation can be annoying write cleanly. For example, I don’t think Prettier will word-wrap strings in back ticks for you (since it can’t know if it’s safe) where as I believe it will word wrap JSX for you since it knows line breaks are safe in white space. (I’m on mobile so I haven’t actually checked)

So, forcing back ticks may also force users to manually handle line wrapping, which can be a bit annoying.

[golopot]

Using fragments for linebreak-less strings can help avoid max-len. Also makes the string formattable by prettier.

<Author
  name="eeee"
  description="eee  eeeeee eee eeeee. eeeeeeee eeee  eeeeeeeeeeeee eeee. eeeeeee eee eeeeeeeeee ee eee eeeeeee eee."
/>;

<Author
  name="eeee"
  description={
    <>
      eee eeeeee eee eeeee. eeeeeeee eeee eeeeeeeeeeeee eeee. eeeeeee eee
      eeeeeeeeee ee eee eeeeeee eee.
    </>
  }
/>;

[ljharb]

max-len should just be wholesale disabled anyways :-) but ok, fair

[golopot]

I have rewrite the fixer to fixes more cases.