RFC: "lift" logic for parsing text to parent component

[Ashoat]

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 determining this.state.text from TagInput. To complete the circle there is also a callback prop this.props.setText that gets called when the user changes the contents of the TextInput.

To be clear, parseTags, this.props.separators, this.props.regex, and this.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.

[JaxGit]

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.

[Ashoat]

I went ahead and created a PR for this: #43