@kentcdodds after some testing on iOS, it turned out the blur handler removed at https://github.com/paypal/react-autocompletely/pull/46 is actually necessary.
Without this handler, dismissing the iOS keyboard (as shown in https://github.com/paypal/react-autocompletely/issues/32#issuecomment-318335025) will not 'reset' the autocomplete controller, and therefore the menu will be left in the open state.
I would be able to implement my own blur handler if all the props of this.autocomplete were exposed (i.e. isMouseDown and reset()).
Let's restore the original behavior and try to about the iOS bug. I sorta figured this would happen 馃槄
In my personal fork of react-autocompletely within a project, I've just restored the blur handler, and only left out moveCursorToTheEnd(this._inputNode).
This seems to be the right direction.
I'll look into a PR later today (I won't mind if someone else does 馃槃).
Pressing done and still seeing the results is the best experience though IMO, we鈥檙e struggling with this too in autocomplete.js --> https://github.com/algolia/autocomplete.js/issues/141
@Haroenv afaik, for react-autocompletely, naturally un-focusing the input dismisses the menu. IMO for consistency, pressing done should still dismiss the menu. But I totally understand the UX angle 馃槃 .
As a compromise, we probably should expose more API to let devs have more fine grain control over their menus.
That way, react-autocompletely won't need to enforce an opinionated UX of menus.
As a compromise, we probably should expose more API to let devs have more fine grain control over their menus.
Yeah, I _think_ that @souporserious's PR #52 might enable this if I'm not mistaken. Either way I think that's a good idea.
FWIW, I almost feel like clicking "done" should leave the input focused, but dismiss the keyboard. That would be the experience I would expect. I'm not sure about whether that's possible though 馃
@kentcdodds PR at https://github.com/paypal/react-autocompletely/pull/52 may definitely help expose some API, and then devs would pass them down as props (or wrap/compose them) to their relevant components.
example: exposing isMouseDown and reset() at getControllerStateAndHelpers(): https://github.com/paypal/react-autocompletely/blob/bd42093ebcad08f672a93d9263917284a5b174f8/src/autocomplete.js#L158
I'm going to do this now.
Fixed
@kentcdodds sweet thanks! 馃憤 I'll check out master when I get the chance 馃槃
Most helpful comment
@Haroenv afaik, for react-autocompletely, naturally un-focusing the input dismisses the menu. IMO for consistency, pressing
doneshould still dismiss the menu. But I totally understand the UX angle 馃槃 .As a compromise, we probably should expose more API to let devs have more fine grain control over their menus.
That way, react-autocompletely won't need to enforce an opinionated UX of menus.