[added] passed through event to onSelect prop callback

[thebigredgeek]

I added the event as the last prop, which breaks convention (onChange passes the event as the first prop) but keeps the interface backwards compatible. The main reason for this change is that preventDefault is needed when the autocomplete is within a form if submission is not desired. Otherwise the form will submit when enter is pressed to select an item from the autocomplete list.

[NerdHerd91]

we have a current release candidate rc1 - might be worth going ahead and being consisted with the prop ordering since that release candidate is a breaking change anyways.

[bfink13]

I agree - it sounds like there will be quite a few breaking changes so I suppose now is the time to do it "the right way" :)

[thebigredgeek]

Yeah I can revise it if that is what we want to do. No worries

[CMTegner]

Preventing form submission when selecting an item in the menu with Return is probably a sensible default behaviour. I created a fix for it in #92.

I'm not sure exposing event via onSelect is the correct thing to do, since there's no real 1:1 mapping between a browser event and onSelect. We just happen to treat Return while the menu is open as onSelect for the moment, but as we add more and more ways of selecting an item, the line starts getting blurry.

onSelect(value, item) is already a very useful interface which delivers the data you need, when you need it (although I'd argue that item is probably more useful that value in most cases). I would go as far as to say that we should, if we can, try to remove event from onChange(event, value). Let's face it: no one wants to do event.target.value to access the input value, and no one wants an unused argument in their code.

[thebigredgeek]

Is there any way other to prevent form submission when the enter button is pressed? It basically defeats the purpose of having Return select an item if the event bubbles up uncontrollably and submits any parent form. Having Return select an item is also just good UX 99.9% of the time when arrow key traversal is supported. Not exposing an interface of some sort to handle this seems like a bad technical design decision and antithetical to the way the DOM works, as does removing the event parameter altogether.

[CMTegner]

It basically defeats the purpose of having Return select an item if the event bubbles up uncontrollably and submits any parent form.

The Return event that selects an item from the menu has defaultPrevented=true, so it shouldn't submit the form. Any Return events triggered from the input while the menu is closed will bubble up. The thinking behind this is that the first return selects an item, while the second submits the form. If you want to override this behaviour you could listen to the form's onSubmit event, or if that won't work we could perhaps add a onKeyPress prop.

[eriklharper]

What's the status/holdup on this change? I could really use the additional event object in the onSelect callback since I need to know if the metaKey was pressed when the user selected an item. I would like to allow Ctrl/Cmd clicking to open items in new tabs, and I think it just makes sense in general to send up the SyntheticMouseEvent into the onSelect callback because you never know when you might need to get a hold of that object.

I also welcome the onFocus and onBlur callbacks as well. This PR looks pretty good to me and would love to see it merged. Thoughts?

To give more context, I'm using Autocomplete as a global search box in which clicking an item routes to a URL for displaying/editing that particular item. I'd like to enable metaKey clicking to allow new tabs to open for convenience when editing multiple items.

[softage0]

Is there any updates for this API?

I extremely need event to remove redundant code for onChange handling.