Default Values > Boilerplate Requirements

[machineghost]

It's truly awesome that someone has revamped the old react-autocomplete and is maintaining it. But at the same time, I feel like .... like this library should be an easy to use autocomplete widget, but somehow it turned into a doctoral thesis on autocompletes ;)

An autocomplete library, at its core conceptual level, should only require exactly one prop: a list of values to complete from, or a function to retrieve those values.

In your Basic Example, the ONLY truly necessary part is "the languages" variable. Everything else in that entire example should be optional, because none of it is truly necessary to make a functional autocomplete ... and yet so much more is required.

Are you making a feature request?

• Please describe your use case from user journey point of view, e.g.:

When most programmers go looking for a library, I think we all just want to "get stuff done", so we go to the docs to do exactly that ... not read an 18-hour treatise. A good library will have every option I could possibly want available ... but it won't force me to learn and use every last one just to get started.

Say I don't want to use AJAX for my autocomplete initially: if so onSuggestionsFetchRequested is required but meaningless. Ditto for onSuggestionsClearRequested.

Likewise, a sensible default for getSuggestionValue would obviously be x => x ... and that would also make a great default for renderSuggestion. And just as in React itself you DON'T have to provide props to an <input />, this library shouldn't require inputProps. The value should default to "" and the onChange should default to another no-op function (() => {}), or just be left out of the HTML entirely if not provided.

It just comes down to: are you trying to make the best possible React autocomplete widget for the React community, or are you stuck on a very narrow use case, and (on purpose or not) making things as painful as possible for every other use case?

Obviously you can't make a library that's everything to everyone, but if you would just set sensible defaults instead of pointless boilerplate requirements, it would make the library much better for many more people, at a cost of ... no harm to anyone.

[aberezkin]

I don't think that this is a library for a "narrow" use case. It's low level so anyone can implement the behavior they want to see in their UX scenarios. It's the opposite of narrow. Most of the issues in this repo in fact are asking about more customizable elements not less.

[machineghost]

I don't think that this is a library for a "narrow" use case.

Exactly my point (that question was meant to be more rhetorical).

If it's intended to be used by anyone, then philosophically one would expect such a library to require as little as possible. But (and this was really the core of the issue) the library unnecessarily requires that things be provided, when they could instead be optional defaults (which could of course be overridden based on user needs).

[moroshko]

At this point, we expose a single Autosuggest component, which is a controlled component. You can think about it as a low level API.

We could definitely explore exposing a higher level components (probably uncontrolled), that would also have some sensible defaults like you are suggesting.

[rafalkrupinski]

+1 to the sensible defaults. Currently the basic case in Readme is ca. 100 LOCs, it should be 20

[machineghost]

At this point, we expose a single Autosuggest component, which is a controlled component. You can think about it as a low level API.

We could definitely explore exposing a higher level components (probably uncontrolled), that would also have some sensible defaults like you are suggesting.

This doesn't make any sense to me. In what way does setting default props require a new component?