Downshift: Where can downshift be improved?

[kentcdodds]

Hey friends! I'm looking for feedback. Where can downshift be improved? This is an open-ended question and I'm looking for ideas. How can we improve the docs? What can we improve about the API? How can the implementation be improved?

A few ideas I have:

1. A legit website with an easier way to add or contribute to examples (I have some ideas here... Maybe it could just be a repo that could be loaded into codesandbox which we'd publish via netlify... Very easy to contribute to via codesandbox's github integration).
2. Some auxiliary component packages that implement a simpler, more opinionated and intrinsically useful autocomplete/dropdown/etc. on top of the downshift implementation.
3. Release 2.0.0 which will remove the breakingChanges prop and also bring improved support for TypeScript and Flow.

Any other ideas? Remember that downshift itself is intended to be extremely flexible, so if what you're looking for is a simpler API, then consider whether you could build a component on top of downshift that exposes that API. If that's possible then let's do it and publish that!

[TrySound]

Remove jsnext:main field in the next major. It was initiated by rollup and deprecated (just with an issue) in it in favour of module field. It's better to not provide dead stuff which others copy in their projects.

[kentcdodds]

Cool! Go ahead and make a PR for that whenever 👌

[9jaswag]

I used downshift for the first time today and I had a need to find out what element was changed in my onChange method. I don't know if there's already a way to get this info but I had to get the id from the stateAndHelpers and add -input to the end of the string before going ahead to find the element in the DOM.
If a better solution for this exists, I'd like to know. If not, it'll be cool to have. (I'll be glad to have my first open source contribution 😄 )

[kentcdodds]

Hi @9jaswag, could you describe your use case further? Why do you need to know what element was changed? And what do you mean by "element was changed?"

[9jaswag]

@kentcdodds I have multiple downshift input fields on a page and in the onChange method, I'm setting selectedItem to state. I want to use the same onChange method for all the for all the input fields on the page.
From my little React knowledge, I do something like this this.setState({ [event.target.name]: event.target.value }) and it sets the matching item in the state.
So, I wanted to do the same thing and I had to get the "name" attribute of the input field whose value was just selected. I ended up doing something like this:

onChange(selectedItem, stateAndHelpers) {
    const element = document.querySelector(`#${stateAndHelpers.id}-input`)
    this.setState({ [element.name]: selectedItem.name })
  }

So assuming the value of the input field with the name attribute username was changed, this.state.username would be set. It would be cool if there was a way to get the element without querying the DOM
I hope I was able to explain it clearly.

[kentcdodds]

Gotcha. Here's what I'd do:

<Downshift onChange={(selectedItem) => this.onChange('first', selectedItem)} />

<Downshift onChange={(selectedItem) => this.onChange('second', selectedItem)} />

Then your onChange could be: onChange(elementName, selectedItem) {. Does that make sense?

[9jaswag]

@kentcdodds Yes, it does. Thanks 😃
What of a situation where the input field is a component? Basically, there's one component with and receives all the props it needs to make an input field? The component will always have only one onChange method.
How do I solve for that use case?

[kentcdodds]

Could you file another issue about that please?

[9jaswag]

I'll do that

[JCofman]

Hi everyone,

I am wondering whether it is a valid use case to render multiple independently dropdown lists inside downshift.

I want to jump between multiple lists and safe the current highlightedIndex. I didn't find an example for that and tried this -> https://codesandbox.io/s/m339x2613p?module=%2Fsrc%2Fordered-examples%2Ftest-multi-dropdown-autocomplete.js but I am wondering whether there is a much simpler solution to that use case. 🤔🙈

Maybe a nice example could be added to the docs.

[alexandernanberg]

Some things I'd like to see in future versions are:

• Smaller bundle size. Not sure how we'd achieve that but Downshift weights in a ~7kb which is a bit much IMO
• Really like the idea of auxiliary component packages. I often use Downshift to implement a <select /> with custom styling. I'd be down to write this package if it comes to that!

[kentcdodds]

It definitely could be smaller, but as far as components like downshift go, it's actually tiny! But we could redesign things a little bit to make it smaller.

I'd really love auxillary packages! We could have many I think that would make things really nice for people.

[Andarist]

Downshift has some nice warnings - I feel that they belong to DEV mode only and we could strip them down for poduction builds, that should save some bytes.

I feel the same about stateChangeTypes - their values dont have to be readable in prod.

[kentcdodds]

I love both of those ideas 👍👍

[kentcdodds]

I think we should also make the build-conditional logic more terse. I think we can do this with a custom macro for this project. Anyone want to take that on?

[Andarist]

I can do it, could you specify what do u mean by "we should also make the build-conditional logic more terse."?

[kentcdodds]

Here's what I mean @Andarist: https://github.com/paypal/downshift/issues/540

This one will be fun :)

[kentcdodds]

Another thing we should consider is improving composition so we don't have to have so much conditional logic. Perhaps create a base component that has the common logic, then expose dom and native-specific components on top of that for the differences... That may make things more complex though... Not less...

[eliperkins]

Perhaps create a base component that has the common logic, then expose dom and native-specific components on top of that for the differences

This would be pretty nice from the React Native side. There's a lot of window or document or DOM-specific things that the React Native version can't benefit from (and aria as a whole in this case too).

I know coming up with primitives to expose to both platforms might lead to some more complex code, but I think it might be nice to figure out a better strategy than what we have so far.

[alexandernanberg]

I did a local test using warning and/or invariant a while back, and the filesize savings was very minimal. I could have done something wrong, although I was using the babel plugin for them.

Anyway, doesn’t hurt to strip the warnings away. But is there a better way than using warning/invariant for this?

[kentcdodds]

I don't expect to save a lot from stripping warnings personally, but it's probably not a bad idea. Let's open another issue for tracking that.

@eliperkins, I agree it's worth looking into. Let's open another issue for tracking that as well. I wont personally have time to work on it though.

[alexandernanberg]

Another thing I've thought about is to maybe move the typescript typings to the DefinitelyTyped project. Then you'd just import then from @types/downshift.

I'm not a TypeScript user so this won't affect me but here is a relevant comment/explanation from a member of the TypeScript team on why we might want to consider this.

[kentcdodds]

Going to go ahead and close this one now :)