Eslint-plugin-react: Warning on props description when props got with destructuring and has passed trough an object

[budarin]

Have this code:

type ComputeMatchTypeT = {
    computedMatch?: MatchT,
    location?: LocationT,
    path?: string,
    strict?: boolean,
    exact?: boolean,
    sensitive?: boolean,
};
...
    static computeMatch(props: ComputeMatchTypeT, context: LocactionContextT): MatchT | true {
        const { computedMatch, location, path, strict, exact, sensitive } = props;

        if (computedMatch) {
            return computedMatch;
        }

        const pathname = (location || context.location).pathname;

        return (path && matchPath(pathname, { path, strict, exact, sensitive })) || true;
    }

Got such warnings: ESLint: 'sensitive' PropType is defined but prop is never used (react/no-unused-prop-types)
This warning presents on props: computedMatch, path, strict, exact, sensitive - because they are not used directly like location.

Redirected from ESLint #9770

[ljharb]

I’m confused why this is reported at all; a static method isn’t a component nor an instance method, so no usages in this method should matter. In other words, you should be able to delete it entirely and get identical warnings. Is that the case?

[budarin]

I'm sorry, but how code processing in runtime is corresponded with statical type analyses?
it's just a function with typed params!
Or I'm wrong?

[ljharb]

eslint is entirely about static analysis.

The no-unused-prop-types rules is meant to apply to React components only; a static class method isn't a React component, so it should be irrelevant to this rule in either direction.

[budarin]

Just have converted this method to usual class method and have changed corresponding calls - nothing has changed.

[ljharb]

In other words, you should be able to delete it entirely and get identical warnings. Is that the case?

Seems like that's the case.

Passing around the props object is a massive antipattern. Instead of doing that, try passing individual props into computeMatch (or an object that's newly formed from destructured properties off of this.props).

[budarin]

In that case props - is not Component's props - it's just this method's props
And passing more than 3 individual params into a function is antipattern (

[budarin]

I'm sorry - you are right!
Destructuring props from other props and passing them into the method as a newly formed object - solves the problem!
My apologizes