-
-
Notifications
You must be signed in to change notification settings - Fork 147
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
Danger setValue #114
Comments
|
…⇒ setCurrentValues() [Closes nette#114]
…⇒ setCurrentValues() [Closes nette#114]
…⇒ setCurrentValues() [Closes nette#114]
…⇒ setCurrentValues() [Closes nette#114]
…⇒ setCurrentValues() [Closes nette#114]
…⇒ setCurrentValues() [Closes nette#114]
is only reason why setValue is marked internal to prevent this accidental error? We have use case where we needs to overwrite user values (user press button and it needs to replace previous values) and I am not sure if we should just ignore internal annotation or if there is another way to solve this. |
Yes, it's only for that reason. |
Hello,
before some time I've been fixing a bug in our project which was caused by using setValue on input instead of setDefaultValue, so typed value by user was overwritten. After investigation I've found same bug across our projects and made by a lot of different developers.
This moved me to think about setValue method which is confusing. Is there any use-case, when it can't be protected? I think, that it's only used in creating custom inputs and then protected or at least @internal annotation should help with eliminating this mistake. Custom inputs are extending input so protected is ok.
In my opinion is this more confusing, than eg. method callbacks so we should think about it.
The text was updated successfully, but these errors were encountered: