Downshift: Controlled vs uncontrolled

[kentcdodds]

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.

[souporserious]

I had this functionality in my last PR 😁 I figured it'd be easier to do after that was merged though. I'll try and get to this today. React-training's example of this is great IMO.

[kentcdodds]

Nice!

TIL:

  state = {
    value: this.props.defaultValue || null,
    showChildren: false
  }

I didn't realize that you can reference this inside class fields. That's awesome. Now I have even fewer reasons to ever have a constructor! :tada:

Are you going to work on this now @souporserious?

[souporserious]

Not right now, please feel free to take it if you'd like :) I have somewhat of a busy day today.

[souporserious]

Maybe test IE though if you're getting rid of the constructor. I remember running into a bug where it choked for some reason when trying to use this in a property.

[jgoux]

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 props on Autocomplete so we can make it controlled without caring about the internal state.

I tried using 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? (Exactly what defaultValue does)

The couple value + onChange props are pretty standard among inputs components.

What do you think?