-
-
Notifications
You must be signed in to change notification settings - Fork 31.8k
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
inputProps and InputProps, no duplicate properties #8232
Comments
Your issue has been closed because it does not conform to our issue requirements. |
P.S. This issue sounds linked to your bundling pipeline. It's working fine with the documentation one. |
The issue is with duplicate props. It is confusing to have two properties with the same name but different capitalisation doing different things. I have not included a codesandbox example because it is more a point about a confusing API rather than an issue. I would strongly recommend that all properties start with lowercase as is the convention in react. Requiring InputProps to start with a capital letter does not follow the usual conventions, and having different behaviour for inputProps vs InputProps is confusing. I don't want to disable the warning, it is in fact correct. It would be preferable if material-ui made a clearer distinction between the two properties. |
I'm not sure if this is something we will move forward to. The naming rule is the following. |
@codepb So, I completely understand that the situation isn't ideal, it's the consequences of tradeoffs. I can't see any better configuration with those constraints. Thanks for raising this point! |
React could do a similar thing though, but instead references html properties by prefixing with html where appropriate. I would suggest that is a better convention to differentiate the properties, as it has more clarity. htmlInputProps references the html element, inputProps references the component. I'm happy to agree to disagree, but I don't see anywhere else where capitalization is used to differentiate in properties, only in component names. |
Because this issue comes up as an early Google result, I'm going to add a link to #10064 which includes a nice workaround:
Seems like deprecating |
providing both inputProps and InputProps raises warning on compilation
Expected Behavior
No warning on compilation. Have different names for the two properties so it's not clashing, and case isn't required. (perhaps htmlInputProps and inputProps)
Current Behavior
If you provide both an inputProps and an InputProps property on a single component there is a warning on compilation that you are supplying duplicate properties as case is ignored.
Steps to Reproduce (for bugs)
provide both inputProps and InputProps
Context
It's confusing, and having warnings on compilation is less than desirable
Your Environment
The text was updated successfully, but these errors were encountered: