Eslint-plugin-react: `display-name` `ignoreTranspilerName` is too strict

Created on 1 May 2017  ยท  8Comments  ยท  Source: yannickcr/eslint-plugin-react

The purpose of ignoreTranspilerName is to ignore inferred names:

const SFC = () => <div />; // inferred name
const Foo = class extends React.Component {} // inferred name

It should not, however, ignore explicit names:

function SFC() { return <div />; } // explicit name
class Foo extends React.Component {} // explicit name

I think that the ignoreTranspilerName option should be deprecated, and replaced with new options that cover the current use cases:

  1. always require an explicit displayName (ignoreTranspilerName: true)
  2. only require an explicit displayName on React.createClasses (ignoreTranspilerName: false)

As well as cover these additional use cases:

  1. always require an explicit name - ie, an explicit displayName or a named function or named `class
  2. always require a name - either explicit, or ES6-inferred
  3. Never allow an explicit displayName? (i don't really care about this one, but it seems useful for consistency)
help wanted new rule question

All 8 comments

@yannickcr @lencioni @EvHaus thoughts?

Voting for option 2!

These aren't exclusive options, they're use cases :-) also there's two lists, which "option 2" do you have in mind?

@ljharb if it can be inferred then I think not explicitly setting a displayName is fine. Anonymous functions or classes though should still be required to have a display name.

export default function() {
  return <span>{'foo'}</span>;
}

This should throw an error.

Yes, that's what it's already doing - but in my example, I need "always require an explicit name", because I never want to rely on name inference.

@ljharb yeah you're talking about having three options right? I agree to that.

  1. Explicit everything.
  2. Inferred if possible otherwise you gotta do it bro!
  3. Do not set a display name.

This is the one that I like that's why I said I like option 2. Now I just realized it could mean the second item in both those lists. Hahaha. ๐Ÿ˜ญ

How about "always" | "only-unnamed" | "only-create-class"?

โ”Œโ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”ฌโ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”ฌโ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”ฌโ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”
โ”‚                                โ”‚ always โ”‚ only-unnamed โ”‚  only-create-class โ”‚
โ”œโ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”ผโ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”ผโ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”ผโ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”ค
โ”‚ function Cat() {}              โ”‚ fail   โ”‚  pass        โ”‚  pass              โ”‚
โ”‚ class Cat extends Component {} โ”‚ fail   โ”‚  pass        โ”‚  pass              โ”‚
โ”‚ export default () => <></>     โ”‚ fail   โ”‚  fail        โ”‚  pass              โ”‚
โ”‚ exports.Cat = () => <></>      โ”‚ fail   โ”‚  fail        โ”‚  pass              โ”‚
โ”‚ const Cat = createClass({})    โ”‚ fail   โ”‚  fail        โ”‚  fail              โ”‚
โ””โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”ดโ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”ดโ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”ดโ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”˜

@golopot exports.Cat = () => {} doesn't have inference; maybe add const Cat = () => {} which should be fail/fail/pass?

Was this page helpful?
0 / 5 - 0 ratings