Constraining the input value of type number to max value does not work (Blazor)

[gurjindern]

`

Number Input
<input id="my-val" type="number" max="@maxInputVal" value="@inputval" @oninput="InputChangeHandler">

@code { private int inputVal; private int maxInputVal = 100;

private void InputChangeHandler(ChangeEventArgs e)
{
    //do something

    var val=e.Value.ToString();
    if (String.IsNullOrEmpty(val))
    {
        inputVal = 0;
    }
    else {

        if (inputVal >= maxInputVal)
        {
            inputVal = maxInputVal;
            
        }
        else
        {
            inputVal = Int32.Parse(val);
        }

    }

    //do something
}

}
`
I am trying to constrain an input value to a max value in the input element box of type number so that if the user tries to put a value exceeding the max value it will automatically set it to the max value on oninput event. the problem is it works only first when you exceed the value, e.g if maxVal=100 and you set 200 in the input box it will change it to 100 but now if you set 1000 it does not rerender the input box with 100. you will see 1000 on UI despite the binding variable is 100. it happens because the binding variable value is still equal to the old value. there should be a way to explicitly rerender the element because there are many use cases in our code where we have to constrain the max value to a certain number.
I am invoking Javascript method to this for now as a workaround.

[javiercn]

@gurjindern thanks for contacting us.

@SteveSandersonMS I believe there was a similar bug reported a few weeks back, can you confirm (and link here?)

[SteveSandersonMS]

I think this is the code you need:

Number Input
<input id="my-val" type="number" max="@maxInputVal" @bind="@InputVal">

@code { 
    const int maxInputVal = 100;

    private int inputVal;
    private int InputVal
    {
        get => inputVal;
        set => inputVal = Math.Min(value, maxInputVal);
    }
}

If you intend to keep the UI in sync with a field then you generally want to use @bind because it knows how to keep the .NET side in sync with the DOM. The code you had before couldn't know to overwrite the DOM value because the render output was unchanged.

[gurjindern]

@SteveSandersonMS Thank you very much, the problem with this is you have to put the change event handler logic into the property setter.

[SteveSandersonMS]

This is a requirement for @bind today, though we do have a backlog item tracking a desire to make this functionality available for regular event handlers too.

Hopefully in most cases doing it through a property setter will work fine.