Unexpected behavior when trying to (not) set .valueAsNumber

[Benexx]

Which package(s) are affected?

Lit Core (lit / lit-html / lit-element / reactive-element)

Description

II'm not sure it is a bug but I do have an unexpected behavior (in Firefox and Chromium) when making a webComponent that wraps a number input (in the full element we show some error messages).
The goal is to no change the user input when he is changing the value (make the field empty, remove the focus or reset the cursor position). It works quite nice except when you preload the element with a .value.

If you don't set the value and type 123- by hand the input is not cleared.
If the value is 123 and you add a - by hand the input is cleared. After this you could type 123- without the input clearing. To reproduce the problem again you need to reload the element.

I tried to make the component as small as possible, we do use an internal variable to prevent unneeded renders for example but in some cases we do trigger a requestUpdate and that will clear the input.

My criteria:

• Allow setting the .value property on the custom element before the first render (default value)
• Allow render() to be triggered while the user is changing the value. We want to show some custom error texts while the user is changing the value.
• Allow changing the .value property after the user did change it

The element:

import { html, LitElement } from 'lit';
import { customElement, property } from 'lit/decorators.js';
import { ifDefined } from 'lit/directives/if-defined.js';
import { live } from 'lit/directives/live.js';

@customElement('number-element')
export class NumberElementComponent extends LitElement {
    
    @property({ attribute: false })
    public accessor value: number;

    public render() {
        return html`
<input 
 type="number" 
 .valueAsNumber=${ifDefined(this.value != null ? live(this.value) : null)}
 @input=${this.handleInput} 
/>
`;
    }

    private handleInput(e: { currentTarget: HTMLInputElement, preventDefault() }): void {
        const value = e.currentTarget.valueAsNumber;
        this.value = isNaN(value) ? null : value;
    }
}

The usage:

html`<number-element .value=${123}></number-element>`

Reproduction

The input should not be cleared when you replace or append a -: Playground

Workaround

We couldn't find any workarounds

Is this a regression?

No or unsure. This never worked, or I haven't tried before.

Affected versions

Fails for lit@3.1.0 and lit@3.1.2

Browser/OS/Node environment

Firefox (123.0.1 (64-bit)) and Chrome (122.0.6261.129 (64-bit))

[augustjk]

Hmm.. is the idea to never modify what's being shown in the input from what the user is typing?

In that case you maybe don't even want to do a value property binding to the element. You can use the value attribute to set the initial value. Then read it directly from the element when you need the current value that the user modified. No input event handling to keep it synced.

If you don't want to adjust the input while the user is typing, but do want to modify it after the user clicks away, then you should handle the change event, rather than input, and you can keep the property binding.

If you do keep the property binding, isDefined() isn't really doing much for you there. It's main use is for attribute binding to actually remove the attribute, but for property binding it's equivalent to setting the value to undefined and you already have a ternary inside.

Because you're also coercing values resulting in NaN to null, Lit's change detection won't be able to tell when the user repeatedly puts in non-number values. The live() can also return a noChange sentinel value which I think is messing with the change detection in why you see the input not changing after manually typing the number and -.

[Benexx]

My criteria:

• Allow setting the .value property on the custom element before the first render (default value)
• Allow render() to be triggered while the user is changing the value. We want to show some custom error texts while the user is changing the value.
• Allow changing the .value property after the user did change it

I tried your suggestion (playground) but it seems that the value attribute is ignored after the first change by the user.

[Totati]

Haha, we had similar issues. This is our solution.

Base on the source

[justinfagnani]

A couple of notes:

• .value isn't typed correctly. You have it typed as number, but you set it to null, so it should at least be number | null.
• You're setting input.valueAsNumber to null when this.value is null and that definitely will clear the input. That much seems expected.
• ifDefined() doesn't really do anything for property bindings
• Directives should usually be the only expression in a binding. If a binding value switches to and from a directive result, the state of the directive will be lost. You almost always want ${live(...)}
• The type property option should be a JS primitive constructor, not a string. 'number' won't do any convertion of the attribute to a number. Number will.

I think one confusing think about this component is that right now the input is "controlled" (meaning it's always set from the outside) when the value is valid, and I think you're trying to make it "uncontrolled" (meaning it keeps it's own state) when the value is invalid.

My guess is that's more difficult to reason about than keeping the input always controlled, but @Totati's suggestion works if you keep it that way. See this updated demo.

If you make your component fully controlled, then you would alway set the value, and either keep the current string value around to set into the input, or add a keydown event handler to prevent entering non-valid characters in the first place. The fact that <input> allows dashes and dots in invalid locations is somewhat surprising. It's a bit more complicated to do this because you want to allow dashes at the start of the value, and input.selectionStart doesn't work for number inputs (why??), so you have to use a plain input. You can see that here

[augustjk]

I think <input> type number allows dashes and dots for negatives and floats. It somehow allows at most two dashes to be present in the field. 🤷

[Totati]

Number inputs are quite smart but hardheaded, just don't want to change the selection, decimal separator, read invalid values or set invalid values 😅. I'm against preventing the user from typing something invalid more than the browser, because that invalid value may be 1 character away from a valid value. It's not possible to differentiate a miss-formatted value from a missing value based on the value of the value or valueAsNumber property, because the first one returns '' the second one NaN for both. However these can be worked out using the validity property of the input.

• User did not fill the input? You can find out checking the input.validity.valueMissing property.
• User typed invalid values? You can find out checking the input.validity.badInput. (It's not accident number inputs allow two - and an e character, -2e-2 is a valid number and Number('-2e-2') will parse it as well)
• You want to allow decimals only? Don't set step, or set it to 1 and check the input.validity.stepMismatch
• You want to allow any number with any precision? Set [step="any"]
• You want to allow 2 decimal places? Set [step="0.01"] and check the input.validity.stepMismatch`

My playground

[justinfagnani]

Yeah, if you don't even want to restrict what the user can type, then even intput/type=number might not be the best choice. Just use a plain input and figure out your strategy representing a value in your custom element for when the string is invalid.

[Benexx]

Using noChange allows us to manipulate the value when we want without strange behavior for the user. Thanks @Totati for the answer!