-
-
Notifications
You must be signed in to change notification settings - Fork 2.8k
Rule option "disallowedFor" for component/dom element prop #2946
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
Comments
We wouldn't do a runtime warning like that; the schema would mark the options as mutually exclusive. That said, your use case seems only for DOM props. What would be the use of it on custom components, which can use PropTypes to forbid specific props? |
Thank you for the feedback @ljharb , I have updated the original issue to notify that the two options would be mutually exclusive You are correct, my use case covers exclusively the DOM props. However I assumed that the logic would be vastly shared between the two rules and that we could kill two birds with one stone. Happy to only implement it where it is needed now Let me know your thoughts |
Bump - We have a use-case where we'd like to be able to ban |
I think it'd be reasonable to add this option for HTML elements only. |
I'd like to work on this! |
Go for it! |
@ljharb I would like to forbid deprecated props for specific Components, which need |
Why? The component itself can do that with its propTypes. |
@ljharb Components are written by TS without propTypes, is there any rule can be used in this case |
Components should always have propTypes even if they have type annotations, since propTypes are much more powerful. If TS types prevent you from using a deprecated prop, why do you need a lint rule for it? |
Hi all 👋
First off thank you so much for this plugin, it has helped me many times, and saved me countless hours of debugging
I would like to put forward an idea to extend the following two rules
The former accepts an
allowedFor
option, and I would like to introduce its counterpartdissalowedFor
.It would be particularly interesting for the
react/forbid-dom-props
rule as the Web platform constantly evolves, and even though it is rare, they sometimes deprecate old attributes.To give you an example, the
<form>
tag used to receive anaccept
argument, however it is now deprecated and that attribute should be set on an<input type="file">
.There are no ways at the moment in
eslint-plugin-react
to express that. I would be happy to implement that directly but wanted to create this issue first to gather feedback from the community and settled on the proper syntax, naming and behaviouraSyntax
To ensure backwards compatibility I believe theallowedFor
option should take precendance over thedisallowedFor
option in the case of the following example, onlyallowedFor
would be applied and a warning would be added to the terminal to notify the developer that they have conflicting rules configurationEdit: as @ljharb pointed out, the following schema would not be valid as the two options would be mutually exclusive
The text was updated successfully, but these errors were encountered: