reactjs/react-autocomplete

Public API: The Basics

Open

#138 opened on Jul 18, 2016

View on GitHub
 (19 comments) (2 reactions) (1 assignee)JavaScript (2,161 stars) (540 forks)batch import
apihelp wantedproposal

Description

tl;dr: We want to make Autocomplete's public API better, and we need your input!

Current API, for reference:

value: any,
onChange: func,
onSelect: func,
shouldItemRender: func,
sortItems: func,
getItemValue: func.isRequired,
renderItem: func.isRequired,
renderMenu: func,
menuStyle: object,
inputProps: object,
wrapperProps: object,
wrapperStyle: object,
debug: bool,

Some thoughts on the current API:

  1. The fact that we need to wrap the input in another element before returning it is an implementation detail (due to how React works) and should not be visible to the user. wrapperProps and wrapperStyle are the main culprits. There is a way to do away with the wrapper entirely - by rendering the menu as a new React tree - but that brings with it extra bookkeeping and logic that we may not want to have to deal with in the long run. It also prevents relative-positioning of the menu, which is only possible when the menu is a child of the same node as the <input>.
  2. The user should be able to think of Autocomplete is an augmented <input> field, and use existing knowledge of the native input controls to quickly configure it. Passing value, onChange, className, placeholder, etc, should just work like it does on a <input> element. Currently the native <input> props are "hidden" behind inputProps, while only the Autocomplete-specific props are exposed as top-level props.
  3. Similarly, the user should be able to expect Autocomplete to behave and react like a native <input> element. Calling instance.focus() should focus the input, and instance.select() should select any text in the input. onFocus and onBlur should be triggered accordingly, as well as any other native event. Arrow keys should navigate text, and return should submit any surrounding form. The consumer shouldn't have to consider tradeoffs when choosing Autocomplete, it should be purely additive.
  4. shouldItemRender, sortItems, and how String#indexOf is used to determine matches in maybeAutoCompleteText should maybe not be of a concern to Autocomplete. We did a big improvement by moving value out of state, and I think we can further improve by handing more responsibility to the consumer.

In my mind Autocomplete is this:

An <input> field with typeahead support and the ability to render an accessible list of options with keyboard and mouse navigation.

I keep this in the back of my mind because it helps me focus on what Autocomplete should be doing above all else.

I suggest - to get started - that we pass all top-level props to the wrapped <input> (minus the ones that are Autocomplete specific, naturally), and thus removing inputProps. This also includes ensuring that any event handler passed in (onBlur, onClick, etc) are attached correctly, even if we use them internally.

Next, I suggest adding all instance methods which one would expect to find on a <input>, e.g. focus, select, blur, etc..

I'll leave this issue open for a bit before we start any work. Hopefully we can get a discussion going to ensure we're heading down the correct path.

Contributor guide