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

forbid-component-props should have a component whitelist #1732

Closed
ThiefMaster opened this issue Mar 20, 2018 · 12 comments · Fixed by #1735
Closed

forbid-component-props should have a component whitelist #1732

ThiefMaster opened this issue Mar 20, 2018 · 12 comments · Fixed by #1735

Comments

@ThiefMaster
Copy link
Contributor

ThiefMaster commented Mar 20, 2018

For custom components it makes sense to have the rule, but when using third-party components violating the rule (ReactModal using className is probably one of the more prominent examples) there isn't much you can do about it...

Having to add eslint-disable react/forbid-component-props comments isn't a very pretty solution.

@ljharb
Copy link
Member

ljharb commented Mar 21, 2018

Makes sense. Maybe we could change the schema (preserving back compat) so that "forbid" can be an array of strings and/or objects following this schema:

{
  propName: string,
  custom: forbid|allow|ignore, // default "forbid"
  html: forbid|allow|ignore, // default "forbid"
  forbiddenComponents: [], // array of forbidden component tagNames,
  allowedComponents: [], // array of allowed component tagNames
}

@ThiefMaster
Copy link
Contributor Author

so forbiddenComponents and allowedComponents would override the value in custom for that particular component? What if someone puts a component in both? Wouldn't it be better to use something like components which could be set to an object mapping component names to forbid/allow/ignore? (what's the difference between allow and ignore btw?)

@ljharb
Copy link
Member

ljharb commented Mar 21, 2018

"custom" and "html" would be only allowing an enum of "forbid", "allow", or "ignore", and would apply to all custom and all HTML components, respectively.

Although yeah, maybe we only need "forbid" or "allow" here.

@ThiefMaster
Copy link
Contributor Author

So, deprecate forbid-(component|html)-props in favor of a new rule forbid-props, that takes a schema like the one we talked about above? I'd go for slightly different names to keep in line with the old rule names though:

{
  propName: string,
  component: forbid|allow,
  dom: forbid|allow,
  override: {somehtmltag: allow, SomeComponent: allow, ...}
}

@ljharb
Copy link
Member

ljharb commented Mar 22, 2018

no, i still think the rule name should be forbid-component-props, i'm just talking about adding a backwards-compatible alternate schema.

I like your suggested schema - "overrides" with an object, same forbid/allow enum.

@ThiefMaster
Copy link
Contributor Author

what would the html/dom entry do in this case? currently forbid-component-props completely ignores lowercase (html) tags...

@ljharb
Copy link
Member

ljharb commented Mar 22, 2018

ah, good point :-) in that case, we'd just need overrides, and the enum value would just be "allow"

@ThiefMaster
Copy link
Contributor Author

{
  propName: string,
  allowedFor: [SomeComponent]
}

@ThiefMaster
Copy link
Contributor Author

PR: #1735

@jsphstls
Copy link
Contributor

jsphstls commented Jun 4, 2019

I am glad this is change was made. What would be the best way to whitelist all components from a package? For example react-icons includes hundreds of components that accept a className prop.

@ljharb
Copy link
Member

ljharb commented Jun 4, 2019

then you’d need a list of hundreds of component names in your config

@jsphstls
Copy link
Contributor

jsphstls commented Jun 4, 2019

This seems to be working:

const icons = require('react-icons/fa')
const iconWhitelist = Object.keys(icons)

'react/forbid-component-props': [2, {
  forbid: [{
    'propName': 'className',
    'allowedFor': iconWhitelist
  }]
}]

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Development

Successfully merging a pull request may close this issue.

3 participants