[BUG] dcc.Input (type=number) callback when pressing arrows

[MM-Lehmann]

Not sure if this is really a bug or intended behaviour but it feels very non-intuitive.

With dash=1.12 and dcc.Input(debounce=True, type='number') you would get some spinner arrows embedded in the component. Unfortunately, with debounce, those do not update the components value until you enter the component (give it focus) and then exit it again. The focus is not set on pressing those arrows, which I think would be the solution. Surely, this can easily be implemented?

[alexcjohnson]

Thanks @MM-Lehmann - moved to dash-core-components where the Input component lives.

I think most of the time the behavior you were expecting is desired, but I'm not sure it always is. If you're debouncing in order to just prevent garbage partial numbers then sure. But if you're using it to delay a slow callback until the user indicates readiness by defocusing the input you may prefer the existing behavior.

There's also the question of whether we can actually detect a difference between typing and clicking the arrows, but I bet there's a way (if nothing else I bet we could check the before and after strings/values to see if they're compatible with typing). But even if we do it may need to be a third value for the debounce prop.

[MM-Lehmann]

When replacing dcc.Input with dbc.Input I noticed that it behaves exactly how I'd described my expectation, i.e. when using the arrow controls, the input field gets focus and thus (when removing focus) the callback gets fired. Wouldn't it be more consistent if both components behaved alike? Could be worth finding out why there is a difference...

And to clarify the above a bit more: I didn't want to distinguish whether the user entered a value manually or pressed the arrows controls. I merely wanted the input field to get focus in both cases instead of just the first one.

[ZackArnold]

I've just noticed this issue myself recently (after misidentifying it as a dash_bootstrap_components problem).

I agree that there are benefits for and against each one of these approaches to treating debounce. I'll just say that, as someone who is using these numeric inputs in an application, I have used some with debounce = True to prevent garbage partial numbers as stated above. When I click the buttons, however, I have treated it as a deliberate choice to increment the value by one or many fixed steps.

I would say it is intuitive that when I type in a value, then go do something else with the page, that my value has been handled by the server due to losing focus. I would not say it is intuitive that when I deliberately press those spinner arrows, then go do something else on the page, the value I see in the box has not been handled by the server because I didn't (seemingly arbitrarily) click the text inside of the box first.

This is a very minor thing of course, and maybe could be resolved with just better UI design on the part of the programmer assuming they are hiding expensive callbacks. I'll admit I am that programmer at the moment, but working my way out of it with some optimizations. That said I do agree with MM-Lehmann that the behavior as it is currently implemented may not be clear to users who have no idea about how Dash works behind the scenes / have never read the documentation.