feat(autocomplete): introduce Multiselect component

[austingreendev]

Description

This PR introduces a new high-abstraction element, Multiselect. This implementation is very similar to Autocomplete, but with the original tweaks present in the AutocompleteContainer example.

Detail

Checklist

• 👌 design updates are Garden Designer approved (add the
  designer as a reviewer)
• 💅 view component styling is based on a Garden CSS
  component
• 🌐 Styleguidist demo is up-to-date (yarn start)
• ⬅️ renders as expected with reversed (RTL) direction
• 💂‍♂️ includes new unit and snapshot tests
• 📝 tested in Chrome, Firefox, Safari, Edge, and IE11

[coveralls]

Coverage decreased (-0.4%) to 93.51% when pulling c9c6b13 on agreen/multiselect-component into 3b15875 on master.

[allisonacs]

do you have this somewhere i can play with it?

[austingreendev]

do you have this somewhere i can play with it?

@allisonacs I've pre-published to https://garden.zendesk.com/react-components/autocomplete/#multiselect it should be the same interaction as the original example built with the render-prop container.

[allisonacs]

IMO, there's an odd interaction in the keyboard nav. If i use the arrow keys to move back through the list (indicated by focus), and then delete a tag, the cursor returns to the end of the input and starts flashing again. Instead, I'd expect it to focus on the tag prior to the left of the item just deleted.

https://cl.ly/0ce3045bab23

[jzempel]

Agreed with @allisonacs (or focus right, depending on RTL).

[jzempel]

This is coming together nicely, @Austin94! Along with Allison's "delete" comment, can you add an example for what it feels like to have a MultiSelect that can add values dynamically? I.e. if I type foo (followed by comma/enter), then that is converted to a tag and added to the list.

[jzempel]

Please add support here for #253

[austingreendev]

Please add support here for #253

@jzempel with this being a high-abstraction component would this be necessary? Users aren't able to combine this with a ButtonGroup or it's equivalent.

[jzempel]

Yes, we want the API to be consistent for all fields. Also, this gets us away from pre-imagining all valid use cases – it's not always about combining with a button. Sometimes there are other space constraints where the focus treatment should appear internal to the field container.

[allisonacs]

@Austin94 I've been chatting with a few folks and came across a use case where the component needs to be able to show a selection/tag which is in error. I can't remember if we had that in the old components—I feel like we must have—but if we don't, let's make sure we get that functionality in here as well (it will be necessary alongside the "add" capability mentioned by JZ above).

[austingreendev]

@jzempel @ryanseddon @allisonacs This is now at a place that matches the original functionality provided in the examples that used the AutocompleteContainer. (I can run locally for you to re-evaluate)

From all of the conversations over the past few weeks, it's obvious that this style of API doesn't fit every possible use case. But, as an intermediary step, this PR should help those that are stuck with the most common implementations.

Some of this ultra-flexibility, like Tag validation, async indicators, and paginated scrolling, should be addressed in a different API/approach that is more flexible than the path we have gone down with this package.

[jzempel]

🎉