downshift-js/downshift

🏎 A set of primitives to build simple, flexible, WAI-ARIA compliant React autocomplete, combobox or select dropdown components.

downshift's Issues

More flexibility, less API?

What do folks think about doing something like this:

const ui = (
  <Autocomplete getValue={a => a.title}>
    {({getInputProps, getItemProps, isOpen}) =>
      <div>
        <input
          {...getInputProps({
            placeholder: 'hello world',
            ref: node => (this.myOwnReference = node),
          })}
        />
        {isOpen
          ? <div>
              {items.map(i =>
                <article {...getItemProps({key: i.id})}>
                  {i.articleDetails}
                </article>
              )}
            </div>
          : null}
      </div>}
  </Autocomplete>
)

The entire API consists of a handful of props you pass to Autocomplete and a handful of arguments you receive in that callback. No need for props like component because you render the component yourself and you call a function to get the props to apply to the component so it hooks up properly with the autocomplete. In addition, there's no need of using the context API anymore which make the implementation a little nicer.

I'm actually pretty excited by this idea (originally inspired by @jaredly a week ago or so). I tried it and it didn't work very well, but now I think I know how to make it work and I think it'll be great. Minimizing the API and enhance the flexibility/simplicity of the thing. I'm probably going to try to implement this as soon as I can. Just wanted to hear your thoughts 😄

Implement react-autosuggest API

Anyone wanna take on this task? By doing this it would really help us know whether react-autocompletely is powerful enough to support these use cases and if there's anything we can do to improve the API.

Favor Array.prototype.filter() instead of Array.prototype.splice() when unmounting Item instances from the menu component

Problem description:

I've been following the streaming of the react-autocompletely and I've noticed some inconsistent behavior (on my re-implementation) when the Item components were unmounting, due to user interaction with the input element.

The removeItemInstance function on the Menu component, which uses Array.prototype.splice(), modifies the array in a non-deterministic way.

Suggested solution:

I propose on using Array.prototype.filter()

removeItemInstance(itemInstance) {
  const index = this.items.indexOf(itemInstance)
  if (index !== -1) {
    this.items = this.items.filter(function(item, itemIndex) {
      return itemIndex !== index;
    });
  }
}

Thank you! 🙌🏻

Edit: It seems that the problem is not with splice but with the way the Items are being rendered.

initialIndex prop

How do you feel about adding an initialHighlightIndex prop so you can do something like highlight the first item when the menu opens?

Clicking down arrow key on closed menu should highlight the first item

Here's an example:

@souporserious, I think this may have happened with your recent changes. Could you give it a look? Thanks!

should 0 index mean no selection?

I'm not sure the official ARIA guidelines here. But should the arrow navigation act in a way where you can always get back to just the text you have entered like in the following gif:

You can test it here. It looks like Google and Facebook searches behave this way as well.

Break up components into seperate files

If you think this is a good idea, I'll work on a PR.

itemToString name change proposal

Are you tied to the name itemToString? After using react-autosuggest, I liked the prop name getSuggestionValue, seemed to be clear what it was. How would you feel about something like getItemValue or even more explicit getInputValue?

Should we invoke onStateChange with _all_ the state?

• downshift version: 1.0.0-rc.3

Relevant code or config

class App extends React.Component {
  state = {inputValue: ''}
  handleStateChange = changes => {
    if (changes.hasOwnProperty('inputValue')) {
      this.setState({inputValue: changes.inputValue})
    }
  }
  render() {
    const {inputValue} = this.state
    return (
      <Div
        css={{
          display: 'flex',
          justifyContent: 'center',
          flexDirection: 'column',
          textAlign: 'center',
        }}
      >
        <h2>basic example</h2>
        <SemanticUIDownshift
          items={items}
          inputValue={inputValue}
          onStateChange={this.handleStateChange}
          onChange={() => {}}
          itemToString={i => (i ? i.name : '')}
          className={css({width: 250, margin: 'auto'})}
        />
      </Div>
    )
  }
}

Reproduction:

https://codesandbox.io/s/5yJ3G59jA

Problem description:

In my handleStateChange handler, I have to check whether inputValue is included in the changes if I want to set the state.

Suggested solution:

What if we just always pass all the state to your onStateChange callback? Then you wouldn't have to check whether inputValue (and other state) exists in the changes.

As I was creating this, I was thinking that maybe we should leave it as it is, because the alternative wouldn't enable you to know what changed, just that something changed.

But what if we did both? So it'd be: this.props.onStateChange(changes, allState)? I think that'd be a good compromise, so I'm going to do that 😄

Controlled vs uncontrolled

Right now this is totally uncontrolled (you can't pass the value in and can only get the value out). We should support controlled (passing the value in as well).

Someone brought up their use case to me in gitter and this is important I think.

Windowing

One thing that could really help with performance is if we window the scrollable area for the autocomplete. I'm thinking that we could either just have an example of how to use this with react-virtualized or if it's not too complex, we could include our own miny implementation of windowing. Thoughts/ideas appreciated!

Look into integrating Lerna

Pertaining to #1. I think it could be nice to have some lib supported packages that included components like Dropdown, or Select. @FezVrasta how did you like using Lerna in PopperJS? Do you think you could help here? I can take a stab at this if it seems worth it.

Remove index prop from Item

I was messing around with sections to replace our current autocomplete and was finding the index prop to be tedious, and then I realized we might be able to get rid of it altogether. Is there any reason you can think of why we can't use indexOf? I added it locally and everything seems to be working 👌

scrollIntoView throws error

scrollIntoView seems to be broken for just the Apollo example. I'll look into this today to see what is going on.

Better isOpen control

I'm only on my phone so I haven't been able to test thoroughly, but since multiple logic has been removed, how should we handle keeping the menu open when selecting multiple values? I've actually wondered if this library should care about isOpen state the more I work with it. We use a Popover component at my work that takes care of this so I'm wondering if other people would face the same use case. I guess you could just ditch isOpen altogether and implement it yourself?

Discussion - Consider to move all example into separated projects

Currently, the examples are in 1 project. It is not flexible if we use many libs. For example, I saw some examples currently are using glamorous . What if I want to use styled-components or material-ui. So I suggest to consider to split examples to different projects.

More props for Input or possible additional component

I'm trying build this react-select multiselect demo and wondering if you have any ideas on how to handle this use case?

Should we add some props to determine how the Input is being used? I'm not sure the best way to handle this with our current setup. Seems like we just need to be able to clear the input value after an item has been selected 🤔

Expose MenuStatus.getA11yStatusMessage

Right now the Menu component uses MenuStatus and doesn't pass getA11yStatusMessage. We should probably allow people to pass getA11yStatusMessage to Menu and have that forward to the rendered MenuStatus.

This should be quite simple for anyone used to React. Especially since we don't actually have any tests yet 😅

Make controlled component easier

• downshift version: 1.0.0-beta.21

Hello all,

I find it still too hard to make the Autocomplete controlled.

The stateProps concept is great for edge cases, but I'd expect to have at least a value prop on Autocomplete so we can make it controlled without caring about the internal state.

I tried using the selectedItem but then I have to handle all other interactions to update it.

I think adding a value props is just a matter of checking if nextProps.value !== this.props.value in componentWillReceiveProps and then update the state accordingly?

The couple value + onChange props are pretty standard among inputs components, and defining a value prop is often what it takes to pass a component from uncontrolled to controlled.

What do you think?

Preact compatibility

hey friends,

I've been trying to get this component to be compatible with preact by using a very thin compatibility layer instead of preact-compat module.

The final component renders fine in a pure preact project without compat but it hits a blocker on this line:

https://github.com/paypal/react-autocompletely/blob/master/src/menu.js#L132

would you be open to changing this single line from:

{children(this.autocomplete.getControllerStateAndHelpers())}

to something like:

React.Children.only(children)(  ..  )

if that's a possibility I think I should be able to complete the out of the box compat.

thanks!

Relying on the id attribute for selecting an item fails for compound components

• downshift version: 1.0.0-beta.21
• node version: 8.2.1
• npm (or yarn) version: 5.3.0

What you did:
Render a compound component as Item.

What happened:
Item does not get selected.

Problem description:
Item get selected only when the target node has the id attribute. With compound components this is clearly a problem.

Suggested solution:
We could walk up the dom tree to the nearest id attribute (maybe use data-item-id) instead.

I think this problem was also mentioned in #110

A note on equlity testing

We should add a note somewhere about equality testing for props like isSelected. This will bite people (me just now ☺️) since objects might not be the 'same' across different render cycles. Maybe in the examples or in a notes section.

Improve accessibility

I'm 99% sure that the current implementation enables users to be completely accessible, but I'd like to widen the pit of success here (by making it easier or, even better, automatic). We do this already with the MenuStatus component which is automatic and how easy it is to add aria- attributes to the things you render. Let's see if we can make it so people don't need to think about accessibility.

With the motivation out of the way, I'd like to use this issue to bring up opportunities to implement automatic accessibility or document recommendations/examples for this. Once we've decided that there's something we should do, we'll open an individual issue to track that specific thing and someone can work on implementing that.

Add a11y attributes to the Input

Based on react-autocomplete in this example here's what the input renders:

<input id="states" role="combobox" aria-autocomplete="list" aria-expanded="true" autocomplete="off" value="">

We should probably add those to ours I think 😄

Should be pretty straightforward for anyone familiar with react.

What can we remove, need to add to getControllerStateAndHelpers?

The getControllerStateAndHelpers function currently exposes a bunch of things which we use to send to the users of the component. What should we add or remove from this?

State:

• value
• isOpen
• selectedItem
• highlightedIndex

Actions:

• toggleMenu
• openMenu - shortcut to toggleMenu(true), nice because you can pass it directly to an onClick={openMenu} rather than having to do: onClick={() => toggleMenu(true)}
• closeMenu - shortcut to toggleMenu(false), nice for the same reasons as openMenu
• selectItem
• selectItemAtIndex - if we were to expose getItemFromIndex, then this could be a shortcut to selectItem(getItemFromIndex(index))
• selectHighlightedItem - shortcut to selectItemAtIndex(highlightedIndex)
• clearSelection
• setHighlightedIndex

Prop getters:

• getRootProps
• getButtonProps
• getInputProps
• getItemProps

I think we should probably expose getItemFromIndex. What else should we expose? What should we hide? Is there a way to restructure/rename things?

If there is no scrollable node it results in an error

• react-kadabra version: 1.0.0-beta.7
• node version: 8.1.4
• npm (or yarn) version: 5.3.0

What I did:
Clicked on the button that opens the list.

What happened:

Failed to execute 'getComputedStyle' on 'Window': parameter 1 is not of type 'Element'.
    at scrollIntoView (utils.js:70)
    at Autocomplete.maybeScrollToHighlightedElement (autocomplete.js:378)
    at Autocomplete.<anonymous> (autocomplete.js:84)

I tried to reproduce here but since codesandbox has a scrollable node at some point the error does not occur. However in local project I can reproduce. Setting the List Container to a maxHeight lower than the height of the contained elements 'fixes' the bug. If you need a repo of the actual behaviour let me know.

Problem description:
If there is no scrollable node it results in an error

Suggested solution:
I guess we should stop traversing the dom at the component boundary and if the scrollHeight equals clientHeight we do not need to scroll into view.

PS. I am love the flexibility the api provides. Great work!

RC release feedback

downshift version: 1.0.0-rc.1

Hello,

As I'm working on a material-ui / virtual-list example using downshift I have a little list of remaining issues :

• The onMouseUp listener seems to force a rerender everytime we click outside of the component, even if there is no state / props changes. You can see the log on my codesandbox demo, try to click outside of the 2 components multiple times.
• The selectedItem prop works great to make the component controlled, but the inputValue gets updated only when we finally click outside of the component (onMouseUp again I think). In my demo, try to select a value in the first component, then you'll notice the second one isn't updated fully until you click outside.
• The scroll management done internally in the lib seems to be in conflict with windowing libraries. I suspect the scrollIntoView and other functions which need to access the items nodes to be the problem. As the list becomes virtual, it tries to scroll to them before they are rendered. I had to do weird tricks to make it somehow workable, like adding this to my input component :

onKeyDown: e => {
  if (
    !autocompleteProps.isOpen ||
    !["ArrowUp", "ArrowDown"].includes(e.key)
  ) {
    return;
  }
  const top =
    e.key === "ArrowUp" && autocompleteProps.highlightedIndex === 0;
  const bottom =
    e.key === "ArrowDown" &&
    autocompleteProps.highlightedIndex === filteredItems.length - 1;

  if (!top && !bottom) {
    return;
  }

  const scrollToIndex = top ? filteredItems.length - 1 : 0;

  // go to the top or bottom of the virtual-list
  scroll({
    scrollToIndex
  });

  // allows to wait that the node to be highlighted is mounted
  setTimeout(() => {
    autocompleteProps.setHighlightedIndex(scrollToIndex);
  }, 0);
}

• The mouse interaction with the virtual-list is fine, but the keyboard one is buggy. When you hold ArrowUp or ArrowDown and the scroll gets too fast, the highlight / focus on item is lost.

• Still virtual-list related, the Enter event listener seems to be active only on initial mounted nodes. When you try to hit ArrowUp, and go at the bottom of the list, you can't select an item hitting Enter.

Don't hesitate to play with my demo to verify all of these issues.

We are almost there, thanks a lot to all contributors for the great work! 👍

value of inputValue is undefined

• downshift version: ^1.0.0-beta.8
• node version: 6.5.0
• yarn version: 0.21.3

Relevant code or config

function BasicAutocomplete({items, onChange}) {
  return (
    <Autocomplete onChange={onChange}>
      {({
        getInputProps,
        getItemProps,
        isOpen,
        inputValue,
        selectedValue,
        highlightedIndex
      }) => (
        <div>
          <input {...getInputProps({placeholder: 'Favorite color ?'})} />
          {isOpen ? (
            <div style={{border: '1px solid #ccc'}}>
              {items
                .filter(
                  i =>
                    !inputValue ||
                    i.toLowerCase().includes(inputValue.toLowerCase()),
                )
                .map((item, index) => (
                  <div
                    {...getItemProps({value: item, index})}
                    key={item}
                    style={{
                      backgroundColor:
                        highlightedIndex === index ? 'gray' : 'white',
                      fontWeight: selectedValue === item ? 'bold' : 'normal',
                    }}
                  >
                    {item}
                  </div>
                ))}
            </div>
          ) : null}
        </div>
      )}
    </Autocomplete>
  )
}

What you did:
I inputed keywork to filter result.

What happened:
inputValue is undefined

Suggested solution:
I replaced inputValue with value. It has worked fine. Just confuse value and inputValue

Item component "item" prop name change proposal

Another one 😇 how do you feel about the Item prop item being changed to value. Seems more natural to write <Item value="apple"/> over <Item item="apple"/>.

Can't unfocus on mobile

• react-autocompletely version:
• node version:
• npm (or yarn) version:

Relevant code or config

https://codesandbox.io/s/9rWEmzEv8

What you did:

Open it on an iPhone, try to press "done", but it doesn't dismiss the focusing

What happened:

Input is permanently focused, not even the url bar is accessible. Can get the focus back out of it when pressing refresh only

Reproduction repository:

https://codesandbox.io/s/9rWEmzEv8

Problem description:

Suggested solution:

Allow the input to blur

Add Label component

Related to #36: One thing that you want for a11y is a label for your input. Normally this is done by putting an id on the input and a for="the-id" on a label. So we could expose a Label component that automatically hooks up with the Input. That could be nice because it could generate a random ID to label the input. If the user provides an id prop to the Input, then we use that.

Example, and question about api

• downshift version: Beta
• node version: 8.2.1
• npm (or yarn) version: yarn 0.27.5

Relevant code or config

Hello! I've been fleshing out a super basic example that is for binding a list of object in the context of Material UI, that' I'd love to submit to the #1 when I've polished more.

see live example: https://codesandbox.io/s/QMGq4kAY

I had a question about the api, and its because I worked last night and also today, and I think I observed some of the values change. So quick questions:

1. is it going to be value or inputValue
2. is it going to be selectedItem or selectedValue
3. also in the version that had selectedItem the function clearSelection seemed to clear both the input and the selected Item (which was convenient), and the new one only clears the selected selectedValue/selectedItem, is there another way to clear the input now? I get stuck with [object object

Thank ya'll for the awesome plugin, so far I really like it!!

Make a real browser/esm/cjs build

Just like in glamorous 😄

I'll be working on this

What can we remove?

I think we are getting to a point where we could move/remove things before 1.0.0. Ideas welcome. I think that we might be able to remove multiple with the new controlled/uncontrolled capabilities. We may be able to merge onChange and onStateChange... What else?

revert removal of blur handler

@kentcdodds after some testing on iOS, it turned out the blur handler removed at #46 is actually necessary.

Without this handler, dismissing the iOS keyboard (as shown in #32 (comment)) 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()).

selectItemAtIndex possible regression

• Downshift: 1.0.0-beta-21
• node version: 8.2.1
• yarn 0.27.5

Relevant code or config

• working example: https://codesandbox.io/s/QMGq4kAY

Before I explain the issue, heres the chunk of code to look for in the demo to be able to reproduce the issue. (around line 131 of the material-combobox.js file)

        const _props = getItemProps({
          value: item,
          index,
          "data-highlighted": highlightedIndex === index,
          "data-selected": selected,

          //This is the important event.
          onClick: () => {
            //selectItemAtIndex(index) //does not work
            selectItem(item); //works    
            //console.log('highlightedIndex', highlightedIndex)
            //selectHighlightedItem() //does not work.
          }
        });

Howdy! :) When I upgraded to 1.0.0-beta.21 from 1.0.0-beta.14, some issues such as the clearing of the autocomplete seem totally resolved and just about everything seems to be working well; however, I think two functions that are means to select items might have regressed (as they dont seem to work for me);

So I have a function that fires onClick. When I use the selectItem function, I can select the item directly, with no difficulty. However two functions, selectHighlightedItem, selectItemAtIndex might have regressed. looking at the code here: my first suspicion would be the selectItemAtIndex, since selectHighlightedItem (line 204) seems to depend on selectItemAtIndex (line 192);

Some important things to note:

• I am logging every state change using the Handler onStateChange and I can see that as I hover over items, and type, the state is properly changing correctly.
• I can also see the desired index is right when I am about to click, and am using the selectHighlightedItem, leading me to believe that it is probably fine itself.
• You can reproduce the behavior by commenting and uncommenting the functions in that click handler
• For me this also seems to affect the 'select on enter' that was working beforehand. This is unsurprising when I look here, (line 363) because the function calls selectHighlightedItem, which calls selectItemAtIndex

Its also possible I overlooked something obvious, and if I did, that won't surprise me at all :) I did my best to update this demo the right way, but if you think I made a mistake when I did, I appreciate the help.

Please let me know if I can add any more info :)

Help make examples

Latest Update:

Alrighty! We're getting really close now! Just need to tie up some loose ends and make sure we cover all the use cases we want to (ALL OF THEM).

We've released an official "release candidate"

You can install it with:

npm install --save downshift@rc

If you want to help, try implementing an autocomplete/combobox/multi-select/etc. with downshift. You can:

1. fork the example codesandbox here
2. give it a good title and description
3. Update the version (go to dependencies, type downshift for the "package name" and rc for the "version"). Do this even though it already appears in the list of dependencies.
4. Add the downshift:example tag. That way it shows up in this search
5. Ping us here when you're done. Thanks!

---

Old Update:

Hey folks! 👋 now that we've released a beta version, it's much easier to make examples. Now you can make them right in the browser 🎉 (thank you @CompuIves!!!)

So, if you've made an example already, would you mind forking this example: http://kcd.im/rac-example and updating it to your example? Then give it a good title and description and add the react-autocompletely:example tag That way it shows up in this search

I'll add a link to that in the README so folks can go see all the awesome examples you all make. Thanks!!!

---

Old stuff

Hey 👋

We need help making examples. I've scaffolded out things for the examples already, but we need more and need to improve the ones that we already do have. Here's a quick rundown of how to get up and running with the examples:

git clone https://github.com/kentcdodds/react-autocompletely.git
cd react-autocompletely
npm install
cd examples
npm install
npm start

Then open http://localhost:3000/example-name

In the examples directory, you'll find a pages directory. Each of those has an index.js file which is rendered at that route. For example, semantic-ui/index.js will be rendered at: http://localhost:3000/semantic-ui

So, the idea for these examples is they can be examples of just about anything. I have a few in there to show examples of how to implement the API or look and feel that other libraries have. That's mostly to demonstrate the power of the primitives available in react-autocomplete.

Feel free to comment here on what example you're working on. You can update an existing example or create a new one. Just let us know so we don't step on each others toes. Thanks!

Oh, and one other thing, right now this repo is private because I need to clear things with legal before we open source it as a PayPal library. So I have to give you commit access. Regardless of that, if you could, please still make forks and don't commit directly to the repo :) Thanks!

Accessibility feedback

Here are some things I found when I tested the component!

What Works

• It works great from the keyboard. Very intuitive, and the clear results button is actionable. 👍
• Great job announcing the number of items available!

What Needs Work

• The input needs a label, as placeholder isn't reliable in every assistive technology. You could use a unique aria-label, or ideally, a <label> element with text wrapping the input (which increases the hit area).
• In Voiceover, you can't navigate with the arrow keys alone so the directions announcing "navigate with the up and down arrow keys" is inaccurate. You could try adding aria-activedescendant to the INPUT pointing to the ID of the currently highlighted item as you navigate. Here's a similar thread you could reference.
• When an item is selected, the a11y-status-message says "no results" (see attached screenshot). It should say which item is selected. Same thing in NVDA and Voiceover.

Note: I can't even get codesandbox.io to load in IE, so I was unable to test it with JAWS.

Name change

Pertaining to #1 I personally think it would be beneficial to choose a name that promotes this library for multiple use cases. I think by naming it anything with autocomplete could paint the library into a corner. I'd love to see Dropdown, Select and other cool components made with this. The hard part is I have no idea what a new name could be 💩

Some quick ones:

• rechoose - react + choose
• reelect - react + elect (maybe just elect by itself?)
• repick - react + pick
• picknic - 🤷‍♂️

Allow multiple values to be selected

I think multiple selection is pretty common, as seen here in react-select. I'm going to take a stab at this since I need it. I sort of implemented something similar already in selectly so hopefully I can just pull all of that stuff over.

Add smaller scroll-into-view

This is to keep track of what was discussed in this PR #15 (comment)

The current dom-scroll-into-view is a pretty heavy dependency. I ran into this same issue in one of my libs. I can PR a smaller version for now that should be a drop in replacement.

Extend auto-selection options

As discussed in #9, explore expanding user options to tailor auto-selection of items to their needs.

Thoughts so far:

• In cases were selection must be a listed item, auto-selection of best match seems appropriate.
• In cases were input is not required to be listed item (e.g. creating a new item), auto-selection of a best match may be counter to intuitive behavior.
• In cases where selection may or may not be a listed item, auto-selection of best match may be preferred, but functionality must exist to intuitively allow user to submit input as-is (no selection).
• Some users type and submit/tab/enter too quickly to recognize that a selection has been automatically selected for them. In this case they will have to go back to the input and change the value, breaking flow.
• Some users would like to use custom submit behavior to delineate selections (e.g. typing a , to delineate a new tag.

Use refs for items in place of data-attributes

Now that we have a way to do this for the root element, how do you feel about taking the same approach for items and allow them to accept a refKey? I imagine there is a small perf win here since we would have access to the node and not have to query it.

autocomplete.js -> downshift.js?

Should autocomplete.js become downshift.js now? So it would be used like <Downshift .../>.

Fine tune babel config

I tried react-autocompletely with a create-react-app project, and attempted to build it (i.e. npm run build), but received this error:

Failed to compile.

static/js/main.9d2e66e4.js from UglifyJs
Unexpected token: punc (,) [./~/react-autocompletely/dist/menu-status.js:60,0][static/js/main.9d2e66e4.js:56374,19]

error Command failed with exit code 1.

---

I believe babel config would probably need some fine tuning: https://github.com/paypal/react-autocompletely/blob/cfc1ffffe38bac9d89555998add9d5ac2024ea40/.babelrc

defaultValue can only be provided on initial render

• downshift version: 1.0.0-beta.12
• node version: 8.2.1
• npm (or yarn) version: 5.3.0

Problem description:
When providing an initial value via defaultValue it will only be 'applied' on initial render. However when that value is only available at an later point (api call) it will be ignored.

Suggested solution:
Use component componentWillReceiveProps to handle the new defaultValue.

If this design is intended and my thinking is flawed feel free to close this issue. Though I would be happy for an explanation.

Contribute to Tests

Hi Kent,

If I want to contribute to tests, what will be the best way to start? Have you considered what functionality should be covered first and move to the next i.e. priority list?

Flow typed

How do you feel about adding Flow to this project? Could even add inline comments while doing this so docs can be generated later.

We could even take it a step further and remove PropTypes in favor of just Flow with babel-plugin-react-flow-props-to-prop-types.

Performance benchmark

Would be great to get an idea of the perf of this component and track that overtime or something. Also to find bottlenecks and speed them up.

Support preact out of the box

@zouhir says he'll be working on this a bit :)