Closed Ashoat closed 6 years ago
A TagInput with autocompletion feature could be a common case. The parent component could handle search and completion/replacement when an option is selected.
Furthermore, we previously had some implementation for another similar but generic case, that the "TextInput" for adding new Tag is also regress to a "+" plus button and Picker. And all we need are the height auto-expending wrapper, the selected Tags, etc.
I went ahead and created a PR for this: #43
I have a use case of this library that isn't quite compatible with the current version, so I've forked my own copy. I thought I'd propose merging that fork into this version in case people think it makes sense, but it's definitely worth a discussion, since it involves removing some logic and would complicate certain use cases.
In case anybody wants to use the forked version, you can find it here. It's missing a few updates from the latest version of this library, but I'll probably merge those in sometime soon.
Anyways, my use case is a typeahead. I want to determine
this.state.text
in a way that's different from this library's default, so I've "lifted" that state into a prop, and basically removed all the logic for determiningthis.state.text
fromTagInput
. To complete the circle there is also a callback propthis.props.setText
that gets called when the user changes the contents of theTextInput
.To be clear,
parseTags
,this.props.separators
,this.props.regex
, andthis.props.parseOnBlur
are all gone in my version.@jwohlfert23 and @sibelius, let me know if you think there would be interest in making this change in the mainline version of this component. I think it makes the component far more flexible and able to support more use cases, but it does force people to implement the
parseTags
logic themselves.