Eslint-plugin-react: Rule Proposal: JSX Fragment shorthand

[dkrutsko]

Hey there, apologies if this was brought up in the past but I'd like to propose a new rule for the ReactFragment feature in React 16. Specifically, the rule would allow you to select between either the shorthand version <> or the <React.Fragment> version.

Additionally, people can also do const Fragment = React.Fragment so allowing them to use a custom tag for fragments as well (probably would just get built-in as prevent both <> and <React.Fragment>.

[ljharb]

This should only apply when the React pragma is >= 16.2; on earlier versions, it should probably warn on both.

[alexzherdev]

This also depends on Babel 7, right?

[dkrutsko]

@alexzherdev I believe you're right, I've recently updated to Babel 7 and I remember it coming up in the patch notes. But only for the shorthand syntax, <React.Fragment> works fine in Babel 6.

[KamiGim]

They already released Babel 7. Just want to inform you guy

[alexzherdev]

So if we have a setting for the name of the fragment tag (i.e. Fragment vs React.Fragment), then this rule could potentially even be autofixable? Otherwise it wouldn't be safe to fix <Fragment> to <>; and in the reverse direction we wouldn't know whether to fix <> to be <React.Fragment> or <Fragment>.

[ljharb]

@alexzherdev yes, I'd expect that just like we have a pragma for React and createElement, we'd need one for Fragment.

Autofixing to <> is thus safe; i think we'd just always autofix to React.Fragment since React is sure to be in scope.

[alexzherdev]

So the pragma would only be used when we prefer the shorthand syntax, and be a no-op otherwise? Would that be intuitive if a team decides to switch from one style to the other?
OTOH, setting the pragma to Fragment doesn't mean you can blanket-fix every <> without making sure that every file has a corresponding import or something. (and it would probably be pretty hard to reliably autofix _that_)

[ljharb]

The fragment pragma would be needed in either case - in "always syntax", as the thing to forbid and to convert from - in "never syntax", as the thing to allow and to convert to.

The fragment pragma would be set to Fragment, and we would always autofix to <${reactPragma}.{fragmentPragma}> when applicable.

[alexzherdev]

Hmm, ok. I’m still trying to understand. I was thinking of the pragma as a way for the user to customize their preferred usage of

<React.Fragment>

vs

import React, { Fragment } from 'react';
<Fragment>

Setting it to Fragment would mean that it’s safe to assume <Fragment> to refer to React Fragment, not some user-defined component.
If it’s always equal to just Fragment, how would we handle the second form in the “always” case? Or would we just ignore it?

[ljharb]

You can’t use jsx unless React is already in scope.

[alexzherdev]

Of course - that was a simplified example, I fixed it. My point is that there’s at least two ways you could refer to <React.Fragment>.

[ljharb]

Oh sure - i don’t think we have to account for that in the first iteration, tho.

[animanoir]

Thanks for this. Now how do I disabled it?

[ljharb]

@animanoir the same way you disable any rule; with eslint config, or an override comment.

[animanoir]

just in case someones search here :

"react/jsx-fragments": ["off"]