Element has 2 behaviors with conflicting value property types about paper-slider HOT 5 CLOSED

FWIW, my proposal would be to remove the value property from iron-form-element altogether and have implementations use their own value type. Right now this would simply mean adding a value property to paper-input.

from paper-slider.

Thanks for reporting the issue. What do you think @morethanreal , @notwaldorf ?

from paper-slider.

Blerg. According to the forms spec, controls have a value, and it's a string, so the IronFormElementBehaviour is correct. Maybe paper-slider needs to cast it to a string?

/cc @cdata for thoughts too

from paper-slider.

I think that also means that we'll need to move IronFormElementBehavior to the end of the behaviors array to get the type right. @sjmiles to confirm. I know it may not matter to Polymer at runtime because it will just cast to a string, but would it matter if you were reflecting to an attribute or something? Either way, I know it matters to the compiler.

from paper-slider.

Sorry, just looked again and realized that IronFormElementBehavior is after IronRangeBehavior, but we assign a number to value, which is why I was getting a type error from the compiler like:

ERROR - assignment to property value of PaperSliderElement
found : number
required: string
this.value = this.min;

This means that we just need to make these assignments strings and we're good :-). I'll send a PR.

from paper-slider.