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

react/jsx-pascal-case warns on components that are all-caps abbreviations #575

Closed
AaronHarris opened this issue Apr 26, 2016 · 3 comments
Closed

Comments

@AaronHarris
Copy link

AaronHarris commented Apr 26, 2016

Some components by a user may contain all caps when it is an abbreviation, eg. <YMCA />, which is still technically valid PascalCase.

In the documentation it specifies that <TEST_COMPONENT> should throw a warning. Obviously it would be impossible for the parser to tell whether a component in all caps is a word or an abbreviation (unless, eg, it looked for punctuation, but even then still not certain).

Would you consider an optional parameter passed to the react/jsx-pascal-case rule to allow all-caps components, or perhaps to specify which component names are allowed to be all caps, would be appropriate?

I'm thinking:

"react/jsx-pascal-case": [2, {"all-caps": true} ]

or

"react/jsx-pascal-case": [2, {"exceptions": "YMCA"}]

Obviously it should still throw an error on components <ymca> or <yMCA>. I'm not sure what solution would best integrate with the rest of the project so open to your thoughts. I use several of these abbreviated components throughout many of my apps.

@ljharb
Copy link
Member

ljharb commented Apr 27, 2016

I like both of these ideas. "exceptions" would be useful in a general case.

@AaronHarris
Copy link
Author

Yeah, I'm still not so sure how well an "exceptions" option would work, since it seems like there are probably workarounds built into eslint (probably some kind of global, or if anything just add an eslint exception at the comment). But if it's something that might be useful to be implemented with other rules, I think it could work.

I think perhaps the lazy/fast way to go is simply to have a string config, either "strict" (default/as-is) or "caps-allowed" so one doesn't have to enter each component that is an exception (since it's not really an exception, but just a misinterpretation by the rule). Both these ideas are technically not mutually exclusive, but I imagine the latter ("caps-allowed" or "all-caps-ok") requires less code change (mostly just an updated regex).

@yannickcr
Copy link
Member

I think we could do both, I'll go for:

  • an allowAllCaps option (Boolean, false by default)
  • an ignore option (Array, [] by default)

(to follow the same options naming as the other rules)

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