Conversation
Nerivec
force-pushed
the
improve-input-submit
branch
from
21e4163 to
52c241a
Compare
| return; | ||
| } | ||
|
|
||
| e.currentTarget.blur(); // triggers onBlur which calls submit, no double-trigger |
There was a problem hiding this comment.
Sharing code between the blur and enter paths makes sense, but I don't think it's desirable for the input to actually lose focus on enter.
There was a problem hiding this comment.
Better consistency if submit always results in same behavior (i.e. the input is no longer focused).
The value could also change in-between (e.g. the backend alters it), which makes the "still editing" behavior, weird.
Overall, I'd say it's better feedback that the value was submitted (also has the side-benefit of preventing accidental multi-triggers).
There was a problem hiding this comment.
I don't know what opinions others might have, but that would be worse for me, since to try several values I'd have to keep switching between keyboard and mouse. That's exactly what motivated me to make #442.
If we want feedback that the value has submitted, that's an independent UX issue. Maybe something could happen like the text or background changes color when you edit it, and then back to normal when it's submitted.
Co-authored-by: Michael Shields <shields@msrl.com>
Nerivec
force-pushed
the
improve-input-submit
branch
from
f2d40dd to
9993405
Compare
2 participants
@shields what do you think about this to provide an "even greater" generic version of #442 ?
We should be able to replace plenty of occurrences throughout the code base, and likely remove sparse "on-site same-ish fix" logic.