[Bug Report][4.1.8] VNumberInput spin buttons can de-sync the display value

[Rhovv]

Environment

Vuetify Version: 4.1.8
Vue Version: 3.5.30
OS: Windows 10 (current)

Steps to reproduce

1. Create a VNumberInput with a v-model or :model-value & @update:model-value combination.
2. Add some custom rules to be applied to the modelValue when it is updated - e.g. manually enforce a minimum limit of 0.
3. Use the spin buttons to reach a value outside the manually enforced limits.

Expected Behavior

When intercepting a model-value change and changing the value, the displayed value in the number input should update accordingly

Actual Behavior

When the spin buttons are used to increment or decrement the value past manually enforced limits, the displayed value retains an incorrect further step even though the value modelValue has been corrected.

Reproduction Link

https://play.vuetifyjs.com/#...

Other comments

I believe this is occurring because the display value is updated before the changed modelValue is emitted. When the modelValue is emitted, it is manually changed. If that changed value is the same as the previous ticks value (which is usually the case), no change in value is detected and thus the display value is not refreshed, thus breaking the synchronization between it and the modelValue. The modelValue does change correctly, which can be confirmed by stepping the other direction with the spin buttons and seeing the resulting step "skip".

[J-Sek]

Interrupting @update:model-value is anti-pattern.

You can accept value and auto-fix in next tick or use watch instead.

[Rhovv]

@J-Sek how would you suggest handling custom limits on the number input in that case? Note that simply allowing a "bad" value even for a tick is not always acceptable, e.g. in situations where that value is posted somewhere else. I would argue the fact that the display value changes before the internal value is "accepted" is a bug. Alternatively, providing some functionality on a VNumberInput to force a refresh of the display value would also solve this problem. As things stand, I'm at a point where I have to consider building my own version of a number input component to replace Vuetify's number input.

[J-Sek]

When using dedicated props (e.g. :min="0" :max="10") we allow typing outside of range, but do not emit (input auto-corrects on blur and up/down) while up/down actions are bound to the range. The approach with watch or hooking into update:model-value event works around those dedicated props.

I guess you do not want the users being allowed to type/paste value out of range and see the exact number until blur. If I remember correctly, this is a side effect of improvements we did 2 years ago and since then the UX has settled. Prior to v3.6.14, when user types "123" and "2" gets changed to "10" while "3" and anything that follows is ignored which may be perceived as a bug unless the input displays hint or the range is somehow obvious. Are you sure your use case specifically requires this behavior back?

[Rhovv]

@J-Sek My use case is something more in the line of:
I want to be able to display values outside the range if my back-end provides those values (including if they are updated periodically), but when a user enters a value I want it locked to the allowed range. I can easily achieve this by simply tracking the focus on the component and setting min or max to something like :min="focused ? min : undefined". However clicking on the spin buttons don't interact with the focus of the component, so the spin buttons then allow the value to be pushed out of range.

As such, my next option, which I think is actually the better implementation, is to simply handle the min/max calculation of the value myself. That allows for much more flexibility. To do that, I can tie the v-model of the component to a writeable computed to send it the proper value and to have some control over the value when it is changed. That (in my opinion) is a logical way to handle this, I don't expect the component to fight me when I want to write my own limit or value checking. And as a matter of fact, the component does not fight me directly. This implementation works properly for user inputs, and it works properly internally for the spin buttons. The component's internal value is actually kept within the limits when using the spin buttons. The issue is that the displayed value is not properly kept in sync with the internal value (and that is specifically when using the spin buttons).

[J-Sek]

I thought #21826 was meant to do what you need - stop enforcing range for external changes (demo).

[Rhovv]

@J-Sek #21826 seems be exactly the issue I also ran into. I'm not sure how to check which release version that went into, but from the merge date and tag dates it seems it should have release with 3.10.6? I happen to be on 3.10.7 currently, so it is definitely possible that I just missed the update with that fix! What I was seeing on my end is exactly that my API would load in values after initial load, which would trigger the component limits, which would trigger a change in value, which would trigger a write back down to the API.

I will add that in your demo, the spin buttons still show weird behavior. When the value is out of bounds, using the active spin button only "seems to do something" once. What I assume is happening is that once again the spin button is updating the display value and then the internal value is blocked from changing. In your demo, click the "set to 15" button and then try to use the down spin button. The display value goes to 14 and successive clicks does nothing more. If you then focus the input field, you can immediately see that the internal value is still 15. Thus, the display and internal values where out of sync!

[J-Sek]

#21826 » 4b4bfa5 » v4.0.0

In your demo, click the "set to 15" button and then try to use the down spin button. The display value goes to 14 and successive clicks does nothing more.

Good catch. Although it definitely can be labeled as "de-sync", I am not sure if it is aligned with the original description of this issue. Please let me know if you agree to reopen this one, or would you rather see it resolved as a separate thing.