Eslint-plugin-react: (react/jsx-key) false positive for a not array .map() method

Created on 5 Nov 2019  路  3Comments  路  Source: yannickcr/eslint-plugin-react

i use library fp-ts@1 and there is, for example, an Option. it has a method map, but it has nothing common with an array type. there is no need in key but eslint thinks differently. i think, it just search for .map( in jsx, but it has to check the type.

const qwe = {
    map: (a: () => ReactNode) => a(),
};
const asd = () => (
    <span>
        {qwe.map(() => (
            <span>qwe</span>
        ))}
    </span>
);

Screenshot 2019-11-05 at 18 57 23

and it does not fail on this, thought it should

const map = <A, B>(m: (a: A) => B) => (as: A[]): B[] => as.map(m);
const asd = () => <span>{map(() => <span>qwe</span>)([])}</span>;

Screenshot 2019-11-05 at 19 00 28

question

Most helpful comment

Similar story here鈥攚e're using an Option type, along with other types that also implement a map method, such as RemoteData/Observable/Either/Validation.

I looked into enabling this rule on our project and it produced 68 false positives. I don't think it would be reasonable for us to add disable comments in that many places.

In any case, I realise our use case is probably the exception, not the rule!

All 3 comments

It is hard to find out the type of a variable in ESLint, so the current cheap solution is to blindly assume that every .map is the array .map. In the future it might be possible to get type informations might with @typescript-eslint/experimental-utils
.

The solution here is to disable this rule, either overall or with an override comment. There's no way to reliably - for JavaScript - determine if a variable is an array or not, so "anything with an array method name" is treated as one.

Similar story here鈥攚e're using an Option type, along with other types that also implement a map method, such as RemoteData/Observable/Either/Validation.

I looked into enabling this rule on our project and it produced 68 false positives. I don't think it would be reasonable for us to add disable comments in that many places.

In any case, I realise our use case is probably the exception, not the rule!

Was this page helpful?
0 / 5 - 0 ratings