Non-component functions that return JSX

[perrin4869]

react-router allows you to override the createElement function when rendering a route component. For example:

<Router history={browserHistory} createElement={createElement}>{...}</Router>

const createElement = (Component, props) => (
  props.route.dependencies = props.route.dependencies || {};
  return React.createElement(Component, { ...props, ...props.route.dependencies });
);

This createElement function is not a component (a component is a pure function of the props, but in this case it has two parameters, the component and the props), however, eslint recognizes it as one and demands that the propTypes be defined. Maybe the component recognition as specified here: https://github.com/yannickcr/eslint-plugin-react/blob/master/docs/rules/display-name.md can be narrowed down to functions with only one parameter.

Edit: the error I get is 'route' is missing in props validation (react/prop-types)

[perrin4869]

Actually, stateless functional components can get a second context component... not sure how to solve this...

[yannickcr]

I was not aware of this functionality of react-router, it's a very special case. Right now I don't see how to handle this but I will think about it.

[mjackson]

FWIW react-motion also allows you to specify a children prop that returns React elements. We're currently working on moving the react-router API even more in this direction, so we need a fix here.

I'd suggest we stop treating any function that returns JSX as a stateless functional component unless we can also prove that someone is using it in a call to createElement somewhere. Since I suspect the latter isn't really feasible, I'd suggest we stop treating functions that return JSX the same as if they were components. They are not the same.

[ljharb]

It's not just any function that returns JSX - it's functions that return JSX and take a "props" (or destructured) first argument, and an optional "context" second argument.

How else would you propose detecting SFCs so that rules can be applied?

[mjackson]

That's not true. I just triggered the react/display-name warning on an anonymous function with a blank argument list.

The only way you can definitively tell that the user intends to use a function as a SFC is to see if they ever use it as the first arg to React.createElement.

[ryanflorence]

How else would you propose detecting SFCs so that rules can be applied?

I think you just have to check if it's anonymous or not. If anonymous, it's not a component.

// don't warn
<Blah stuff={({ foo }) => ()}/>

// warn
const Thing = ({ foo }) => ()

Note, maybe anonymous means something else, another way to phrase this is "is the function we think is a SFC assigned to a variable or not?"

[ljharb]

Yeah, all arrows are anonymous, but I think you're saying, a "maybe SFC" (the current rubric, which as @mjackson points out might not be as smart as I think it should be, including the fact that SFCs don't have to use props at all) that is also exported or assigned to an identifier - as opposed to one that's passed directly as an argument to something that's not React.createElement.

I think regardless that the metric for detecting SFCs needs to be as accurate as possible, and it's highly likely that it's both not, and inconsistently applied. However, it's far better imo to have an overly-active lint rule that can be overridden with comments, than to have one that misses otherwise lintable errors.

[ryanflorence]

What's wrong w/ keeping your current metric and adding "assigned to a variable"? Is there ever a case where you have a SFC that isn't assigned to a variable?

[ljharb]

export default () => <div />

[lencioni]

@ljharb

It's not just any function that returns JSX - it's functions that return JSX and take a "props" (or destructured) first argument, and an optional "context" second argument.

Not all SFCs take props though, right?

[ljharb]

@lencioni yes, you're right - i mentioned that in #512 (comment)