Fix handling of negative zero in number selectors #17127
Conversation
| @@ -64,7 +64,7 @@ export class HaNumberSelector extends LitElement { | |||
| class=${classMap({ single: this.selector.number?.mode === "box" })} | |||
| .min=${this.selector.number?.min} | |||
| .max=${this.selector.number?.max} | |||
| .value=${this.value ?? ""} | |||
| .value=${Object.is(this.value, -0) ? "-0" : this.value ?? ""} | |||
There was a problem hiding this comment.
Too much of a hack IMO. We should fix this more generically in ha-text-field, unless it only occurs when using ha-selector-number?
There was a problem hiding this comment.
I am not sure if it is possible to fix in ha-textfield.
ha-textfield extends mwc-textfield, where value is a string property.
The issue is that when user types "-0", we get a event with value "-0" from mwc-textfield and convert it to Number, which is -0.
Then when we next render the ha-textfield, we set value to -0. But since value is a string, the number is implicitly converted to string. Unfortunately Number(-0).toString() is "0", not "-0".
Without changing ha-textfield to accept number types, it never sees the -0 input.
I'm not sure if there is such a thing as a "more generic" fix, since I believe 0/-0 are the only numbers that have this issue.
There was a problem hiding this comment.
I guess if there was an alternative fix, it would be ha-selector-number storing the value from the textfield as a string instead of a number. Haven't thought through the implications of that though.
That might fix a minor issue where if you enter 0.001 and hit backspace, it switches to 0 and not 0.00
There was a problem hiding this comment.
I guess I was assuming that the issue was caused by autocorrection in ha-text-field. If that's not the case and it's instead caused by string coercion, then we should better control that and get rid of the type incompatibility.
There was a problem hiding this comment.
Ok I've uploaded an alternative fix that I think I like better, it fixes more cases of text field changing value unexpectedly.
selector now tracks the string in the textbox in addition to the number provided by the property, and only overwrites the string when converting that string to a number gives a different value than the number provided by the property.
Let me know if that looks better.
|
I think this can be fixed by not calling |
|
What btw is also very annoying is that if you empty the input with backspace, it is immediately filled with the default value: (at least when used in a blueprint)
|
I don't feel like that would work right. If for example the field is undefined, and you type in Or if you have type -0.5 in the field, and hit backspace, then it will not update and the yaml will remain at -0.5? |
Huh I thought that was maybe something I fixed back in #16196. I think at the time I was only looking at text selectors though, maybe something unique about number causing this. Kind of feel like that's maybe an unrelated issue though? edit: checked and looks like that fix only works for selectors that have string-type values. |
|
There hasn't been any activity on this pull request recently. This pull request has been automatically marked as stale because of that and will be closed if no further activity occurs within 7 days. |
|
I still like this fix and would like to see it merged. |
Proposed change
Fix some quirks around number selector and negative decimals.
It was difficult to input the value
-0.5in a number selector because if I clear the field and enter-0it was immediately replaced with0by the ha-textfield. So typing-0.5was giving0.5The only way to enter it was to enter
0.5and then move the cursor to the front and add in the-.This PR fix that behavior so
-0is not modified.Type of change
Example configuration
Additional information
Checklist
If user exposed functionality or configuration variables are added/changed: