You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
This repository has been archived by the owner on Dec 19, 2024. It is now read-only.
iron-validatable-behavior is kind of like an interface which says: I have a valid/invalid state and someone can ask me to validate myself. It doesn't say anything about what kind of value the element has. Yet the validate() function takes a value parameter. If you were implementing a generic validator that validates its children in a generic way, you wouldn't know what to pass to this function. You could even pass arbitrary nonsensical values to this method which have nothing to do with the current state of the element. This makes the contract/responsibility quite unclear. If an element has this behavior, it should have a validate() without parameters, and it would be implemented by the element such that it knows how to validate itself. Each element should read its own state because it knows how to.
iron-form is a good example of a generic validator. It even happens to know that the element has a value (through iron-form-element-behavior, different story), but doesn't pass it when validating (which is a very strong point by itself, as this should be one of the main players in the validation business, making the presence of the value parameter generally unlikely). See: https://github.com/PolymerElements/iron-form/blob/0078ac58c4b240d34373ffc380af065f7a3e7b19/iron-form.html#L382
One way to solve this is just removing the parameter from validate() and let the elements using this define their own implementation. Another is getting this.value, which should usually work (not nice, but it's better done inside Polymer than by external users of these methods). Or you could define a new behavior that mandates the presence of a value property, and both iron-validatable-behavior and iron-form-element could extend from that. Or iron-validatable-behavior and iron-form-element could be merged.
The text was updated successfully, but these errors were encountered:
iron-validatable-behavior is kind of like an interface which says: I have a valid/invalid state and someone can ask me to validate myself. It doesn't say anything about what kind of value the element has. Yet the validate() function takes a value parameter. If you were implementing a generic validator that validates its children in a generic way, you wouldn't know what to pass to this function. You could even pass arbitrary nonsensical values to this method which have nothing to do with the current state of the element. This makes the contract/responsibility quite unclear. If an element has this behavior, it should have a validate() without parameters, and it would be implemented by the element such that it knows how to validate itself. Each element should read its own state because it knows how to.
iron-form is a good example of a generic validator. It even happens to know that the element has a value (through iron-form-element-behavior, different story), but doesn't pass it when validating (which is a very strong point by itself, as this should be one of the main players in the validation business, making the presence of the value parameter generally unlikely). See: https://github.com/PolymerElements/iron-form/blob/0078ac58c4b240d34373ffc380af065f7a3e7b19/iron-form.html#L382
One implementation of validatable is iron-input. Its validate() function doesn't even have a parameter, it takes its own value by itself: https://github.com/PolymerElements/iron-input/blob/2d43ba1f4809ce1769e565c2a8150da2a2dedbab/iron-input.html#L280
Another is paper-drop-dropdown-menu, which defines the value parameter but then ignores it and takes its own value by itself:
https://github.com/PolymerElements/paper-dropdown-menu/blob/96aea61522e8ca1f82eaab1b5204a42c931d166b/paper-dropdown-menu.html#L377
One way to solve this is just removing the parameter from validate() and let the elements using this define their own implementation. Another is getting this.value, which should usually work (not nice, but it's better done inside Polymer than by external users of these methods). Or you could define a new behavior that mandates the presence of a value property, and both iron-validatable-behavior and iron-form-element could extend from that. Or iron-validatable-behavior and iron-form-element could be merged.
The text was updated successfully, but these errors were encountered: