Function that returns a component causes false positive unused react/prop-types warning in typescript

[DamianPereira]

The folllowing code causes a false positive for the react/proptypes, with 'className' missing in prop-types declaration. Since this is typescript, and ComponentProps includes className, I'd expect this to not happen.

import * as React from "react";

type ComponentProps = {
  className?: string;
};

class Test {
  getAComponent(): React.FC<ComponentProps> {
    return function ComponentName(props: ComponentProps): React.ReactElement {
      return <div className={props.className}>Hello</div>;
    };
  }
} 

const test = new Test();
const Comp = test.getAComponent();

export default function App(): React.ReactElement {
  return (
    <div className="App">
      <Comp className="text-success" />
    </div>
  );
}

If the component is instead defined outside of the method that returns it, then the warning dissapears, like this (the rest of the example remains the same):

const getAComponentNotInClass = function ComponentName(props: ComponentProps): React.ReactElement {
  return <div className={props.className}>Hello</div>;
};

class Test {
  getAComponent(): React.FC<ComponentProps> {
    return getAComponentNotInClass
  }
} 

[DamianPereira]

Added a repo with the code and relevant config/packages here. Just run npm install, and npx eslint Example.tsx.

[ljharb]

I'm confused; you have a component factory in a class method?

[DamianPereira]

Yeah, the real example is a component generator that is used like
const PaddableDiv = classed.div((padded) => padded ? 'p-3' : '')
Then you use it like this:
<PaddableDiv padded={true}/>

Previously I had methods like makeClassedDiv() or makeStyledH1(), but classed.div and classed.h1 make for a nicer looking interface and keeps all methods self contained, which is also nice. In order to do this classed.div() needs to take the styles (classnames) to be applied and return a react component as a function, not a ReactElement.

I did the smalles possible test case I could do, but there's a real use case behind it. I can provide a bigger example if you prefer that, but anyway, this is a false positive right? Or is there something I'm doing wrong?

[ljharb]

I think that since it's working when declared at module level, but not when inside this class method, that there's definitely a bug.

[DamianPereira]

There are 2 scenarios that are added as tests, both passing as valid, but one of them should not be. This one:

import React from 'react'
class Factory {
  getRenderFunction() {
    return function renderFunction({ name }) {
      return <div>Hello {name}</div>
    }
  }
}

In this one intended to not raise a warning because the function has no caps?

[ljharb]

Yes - <renderFunction /> wouldn't work, so that's not a component.

[k-funk]

In my case, I'm also getting false-positives for react/prop-types in my typescript project, only when i use the name props

{[{ label: 'Thing', value: 'thing' }].map(props => <MyComponent key={props.value} {...props} />)}

If i change the arrow function's name from props to something else, no error.

Seems someone else had the same issue, but in my case i'm spreading props, so I can't destruct like the accepted answer.

---

Side Note: is there a codesandbox/playground for this plugin, so it's easy to demo issues to maintainers?

[ljharb]

@k-funk could you file a new issue for that?

There isn’t a playground I’m aware of; the best way to demo the issue is a PR with a failing test case - the second best way is a repro repo.