prohibit && conditional rendering in the return statement of a component

[graingert]

// avoid
const WrapTingy = ({ cond }) => (
  cond && <Tingy/>
);
 
// that would error if cond is `undefined`, use this version instead:
 
const WrapTingy = ({ cond }) => (
  <>{cond && <Tingy/>}</>
);

[ljharb]

This seems like a very niche use case; if it’s trying to address the issue of conditionally rendering the wrong thing, it’s not doing enough, and if it’s only trying to address the return error, I’d say the prop-types rule would handle that - iow, this component is missing a required propType.

[graingert]

still a problem when you want to have an optional value:

// avoid
const WrapTingy = ({ items }) => (
  items && items.length && <Tingy items={items}/>
);
WrapTingy.propTypes = {
  items: propTypes.array
}

[ljharb]

React.Fragment is only available in 16.2+; fragment syntax requires babel 7 - this isn’t really a broadly available solution yet.

I still feel like this is a runtime warning, not a linter warning. If we did handle it in a rule, we’d have to figure out if a propType is required or not (and this isn’t statically possible on a custom propType), and only error when it’s optional or when the propType is missing.

[graingert]

Other options without fragment are:

const WrapTingy = ({ cond }) => (
  cond ? <Tingy/> : null
);

const WrapTingy = ({ cond }) => (
  (cond && <Tingy/>) || null
);

const WrapTingy = ({ cond }) => (
  !!cond && <Tingy/>
);

[graingert]

I still feel like this is a runtime warning

This is only a runtime error when cond is undefined in development people might execute that branch

[harsh-tamr]

or !!cond && <Tingy/>

[steelbrain]

Opened a PR for this @ #2888

[ljharb]

@steelbrain this issue doesn't have "help wanted" or "accepted" labels, which means the new rule isn't necessarily something we'll accept. I'll take a look at the PR, though.

[ljharb]

I'm happy to keep discussing on #2888, but I think this can be closed.