The road to 1.0? [discussion]

[bruderstein]

I'm just going to throw this out there - it's just a collection of thoughts, possible ways forward - I wanted to start a discussion around this. I also know Jed's crazy busy at the moment (I think he's won github), so I'm only writing this now as I wanted to try to put down what I've been thinking about.

Some of these ideas are stolen borrowed from #114 from @chenglou and #227 from @brianreavis, but they also contain a number of other very valid points that should be addressed separately (this issue is meant as an extension of those two).

What have we got?

We've got a component that can do a lot of things by itself. There are currently 36 props, allowing for all manor of possibilities with custom rendering, multiple values, async options, including around 6-7 props to turn stuff off. Whilst we have a reasonable test set, we can't possibly test every combination of options (that would be a lot(!) of tests)

There's a backlog of issues (92 currently) and PRs (36 currently) that various people have been working on, updating, testing, closing etc.

What do we want?

I can't answer that, so I'll answer the "What do I want?" question instead - it'd be great to hear more opinions on this. I think I want a component that I can easily make into any kind of combo box, be it multi-select, custom rendered options/values, using custom objects (e.g. immutable) for the option list, but also it should "just work" with a simple array of values. Supporting asyncOptions via a fire-and-forget flux pattern should be possible too, currently that's pretty hard to do (at least, I think it is, I'd love to be wrong on this!)

I want the ability to create my own custom filtering system, possibly highlighting my search text in the matching results, possibly using fuzzy matching, whatever i choose to implement. However, I also want to be able to just set searchable={true}, and it just work out of the box, without defining a search algorithm, or needing to import Yet-Another-Library.

Being able to choose between controlled (value and onChange) and uncontrolled (initialValue prop) would also be nice.

How do we get there?

My suggestion is that this should be two public components.

Component 1:

The base. This does no filtering itself, nothing smart, doesn't remove already selected options, potentially can't even render an option by itself, and needs an optionComponent passed in. However, it's beautiful and simple and supports an open / closed menu, focus, and has a search box if requested. A dumb component in every sense of the word.

Component 2:

Component 1's big sister. Smart. Has filtering (possibly via sifter), possibly the existing filtering (potentially simply included in an addons directory, that can be required if desired). Can work out what options have already been selected. Wraps Component 1, and passes in the necessary values to Component 1.

By splitting the component up, this allows people to create their own custom combo easily, building on top component 1 (possibly pulling in bits of component 2 where desired), but also allows for use cases that need a works-out-of-the-box, much-better-than-default combo/multi select box.

In order to get there, we need to split things up even more, I think.

var BaseSelect = React.createClass({

//... 
render () {
   // ...
   return (
      <div className="Select">
         <SelectedValues values={values} />
         <SearchInput value={searchValue} onChange={onSearchChange} />
         <Menu options={options} />
      </div>
   );
}
}); 

Obviously lots of things to consider here, and obviously only rendering the <Menu> if it's open etc.

OK, you can start hurling your virtual tomatoes......... now!

[JedWatson]

Closing in favour of #568