Refactor Field validation
See original GitHub issueProblem statement
Currently, field.validator_
is called in some of the methods of classes that inherit from Field, but not called in the Field class itself (whether by callValidator(..)
or more direct methods). When and where the validators are called in the field classes is not standardized and therefore makes coding and fixing bugs for all field types difficult. It would therefore be more consistent to have the callValidator(..)
method called in the Field setValue method.
Issue Analytics
- State:
- Created 5 years ago
- Comments:8 (1 by maintainers)
Top Results From Across the Web
Refactoring Forms - VeeValidate
Refactoring vee-validate is no different than refactoring regular Vue.js components, by inspecting the template of the last example you should notice that all ......
Read more >Refactoring step by step: extract validation logic from a method
Refactoring step by step: extract validation logic from a method · Step 1: “validate and throw” · Step 2: extract each validation as...
Read more >Refactor validation rule show error message if sum of number ...
It should show and error message if the sum of a number of fields must equal the value in another field when saving...
Read more >Validation - Refactoring some code - Morioh
Refactoring some code. We are going to put a validation function in Form . This means that Form needs to know about all...
Read more >How to refactor multiple guard statements for textfield validation?
And if you want to show errors for all fields that were not filled at once, that could be all right. But if...
Read more >Top Related Medium Post
No results found
Top Related StackOverflow Question
No results found
Troubleshoot Live Code
Lightrun enables developers to add logs, metrics and snapshots to live code - no restarts or redeploys required.
Start FreeTop Related Reddit Thread
No results found
Top Related Hackernoon Post
No results found
Top Related Tweet
No results found
Top Related Dev.to Post
No results found
Top Related Hashnode Post
No results found
Top GitHub Comments
I think @BeksOmega’s suggestion will work, and it looks like it’ll work for backwards compatibility. This is another case where we should have tests that are the same before and after, to verify that existing implementations continue to work.
Closing as the original issue is fixed, and I think the secondary events issue was a misdiagnosis of the problem.