Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

displayName JSX #75

Closed
Cellule opened this issue May 6, 2015 · 4 comments
Closed

displayName JSX #75

Cellule opened this issue May 6, 2015 · 4 comments

Comments

@Cellule
Copy link
Contributor

Cellule commented May 6, 2015

Would it be possible to add an option to displayName to consider the jsx transpiler. What I mean is with something like
"displayName": [1, "jsx"]

The following patterns are considered warnings:

module.exports = React.createClass({
  render: function() {
    return <div>Hello {this.props.name}</div>;
  }
});

The following patterns are not considered warnings:

var Hello = React.createClass({
  render: function() {
    return <div>Hello {this.props.name}</div>;
  }
});
@zertosh
Copy link
Contributor

zertosh commented May 6, 2015

@Cellule FYI: Your first example would not get a displayName if you're transpiling with facebook's transform (react-tools/jstransform/reactify/etc). With babel, when using ES6 module syntax, it'll infer the displayName from the filename. http://babeljs.io/docs/usage/jsx/#additional-changes

EDIT: I'm not saying this rule wouldn't be useful. Just letting you know that that is a thing.

@Cellule
Copy link
Contributor Author

Cellule commented May 6, 2015

I didn't know that babel would add it from the file name, it's good to know. However, I am not using babel everywhere yet and I think it would still be useful to have a rule to force the developer to assign a name to its components even when using jsx.
I suppose the rule could check for export default and not warn when no variable nor display name is specified

@yannickcr
Copy link
Member

Currently the display-name rule enforce displayName to be set whenever you're using JSX or not.

What you suggesting is a more sloppy mode when the rule only enforce displayName if we directly export the component with module.exports ?

If yes, I think this is something feasible.

@Cellule
Copy link
Contributor Author

Cellule commented May 7, 2015

yes, that's pretty much what I mean. The idea is to make sure you have a displayName even when transpiling jsx

NickStefan added a commit to NickStefan/eslint-plugin-react that referenced this issue Jun 22, 2015
* 'master' of github.com:yannickcr/eslint-plugin-react:
  Add require-extension rule to Readme
  Add acceptTranspilerName option to display-name rule (fixes jsx-eslint#75)
  Added support for prop-types check of type `this.props['this-format']`. Used list of nested names instead of dot-separated names to avoid conflict with properties like `this.props['this.format']`
  Fix crash if a ClassProperty has only one token (fixes jsx-eslint#125)
  Fix `prop-types` desctructuring with properties as string.
  Added support for prop type identified by strings in rule `jsx-sort-prop-types`
  fix detection of missing propTypes validations on ecmaFeatures.jsx false
  fix detect missing displayName in React class when ecmaFeatures.jsx is false
  Allow blocking of '.jsx' extensions with `require()`
  Point directly to mocha instead of symlink in .bin. On Windows the file in .bin is not a symlink. Inspired by solution in eslint
  Support nested prop types and use react propTypes to make further analysis. Minimal analyse of primitive propTypes.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Development

No branches or pull requests

3 participants