Open AmaiKinono opened 1 week ago
Yeah, I agree. Ideally, we would use the same behavior as in HTML, add a new input
event for the current behavior, and make change
only trigger when committing the value.
I would also add to this that we should only emit any of these events when the user initiates the change, not when changing it programmatically. I believe that is how HTML behaves, and it might also solve some binding loops like in #701, and events being emitted upon initially setting the values.
This would be a breaking change though. Although, I'm not sure how bad of a breaking change it would be, maybe in many/most causes it would still work fine. Needs some testing I think to understand the implications. It might be we'll have to wait to merge it until the next major version change.
we should only emit any of these events when the user initiates the change, not when changing it programmatically.
I'm looking into this, as it seems to be better done before we add the HTML change
event (for now I think we could have a name like changeend
. We can rename it in the next major release).
I plan to change Core/Elements/ElementFormControl.h
:
SetValue
which is a flag of whether the change comes from the user, and it can have a default value of false
.SetValue
implementations of specific form controls, and modify its call sites when suitable.Does this look reasonable to you?
Yeah, it generally sounds reasonable to me.
I do wonder though if, or to what extent, the emit only on user interaction is a breaking change.
Minor design input: I would prefer a strong enum over a bool. Also, I think it's not ideal to have virtual functions with defaulted parameters. Consider using a protected virtual "impl" function with no defaults, and a public one with the default parameter. Not sure if we actually need to publicly expose the second parameter to users though?
The
change
event we have for now seems to be more close to theinput
event in html. This MDN doc explains the difference betweeninput
andchange
:This describes when is
change
event fired.I'm thinking whether we should have an event type like
change
in html, which is useful at times, e.g., to normalize user input, to record an undo checkpoint, etc.For range sliders, I think (in html) the
input
event is fired during dragging, andchange
is fired upon releasing the mouse.