You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Use case: We need an <AutoComplete /> that enforces that the value in that field is either empty or came from the auto-complete list.
In the current implementation of <AutoComplete />onClose is called before onNewRequest. This makes it impossible to detect when a user hits esc or clicks away without selecting a value from the list.
Possible solutions
If onClose was moved to be called afteronNewRequest, users could implement an onUpdateInput method that would mark the input as "dirty", and a onNewRequest method that would mark the input as "clean". Then the onClose method could check if the input was clean or not, and update the value accordingly.
I'm not sure if anyone is depending on the call order of onClose happening before onNewRequest and therefore if making this change would be desirable, or a breaking change.
We could add a new optional onCancel callback to <AutoComplete /> that is called when the esc key or "click away" happens.
This has the advantages of not changing existing functionality, is more explicit.
If this sounds like the type of thing this project would be interested in, I'd be more than happy to open a Pull Request with either direction.
The text was updated successfully, but these errors were encountered:
Description
Use case: We need an
<AutoComplete />
that enforces that the value in that field is either empty or came from the auto-complete list.In the current implementation of
<AutoComplete />
onClose
is called beforeonNewRequest
. This makes it impossible to detect when a user hitsesc
or clicks away without selecting a value from the list.Possible solutions
If
onClose
was moved to be called afteronNewRequest
, users could implement anonUpdateInput
method that would mark the input as "dirty", and aonNewRequest
method that would mark the input as "clean". Then theonClose
method could check if the input was clean or not, and update the value accordingly.I'm not sure if anyone is depending on the call order of
onClose
happening beforeonNewRequest
and therefore if making this change would be desirable, or a breaking change.We could add a new optional
onCancel
callback to<AutoComplete />
that is called when theesc
key or "click away" happens.This has the advantages of not changing existing functionality, is more explicit.
If this sounds like the type of thing this project would be interested in, I'd be more than happy to open a Pull Request with either direction.
The text was updated successfully, but these errors were encountered: