clarkus
commented
2 years ago I've been working on this a bit. There are a few usage patterns I think we should consider. Each component pattern has pros and cons that make the more or less suitable based on those usage patterns.
- Are we picking from a finite list?
- Are we collecting delimited free-form keyword values?
- Are we summarizing rules composed of multiple parameters?
- What event triggers the "add" or "select" action for the list? If we're adding a bunch of free-form data-attributes, then a low-friction event like a keypress on the delimiter character makes sense. If it's more complex like a multi-parameter filter rule, then it happens on button click. These events call for slightly different affordance in the component - as an example, the data-attr creation would communicate better in a text-area-like style, while the multi-parameter filter rule doesn't benefit as much.
- Of the values entered
- Does the order matter? Can items be reordered?
- What's the expected volume of values entered? Are there typically a lot, or just a few?
- What's the average character account for each item? Longer values take up more space and might exceed the boundary of a more tightly-contained list.
- Can the item be edited inline?
- Can it be reordered?
- What's the context of the component? Is it in the page with lots of space to fully describe the list of selections, or is it in a more tightly contained component like a query builder.
Fields that contain a high volume of options, options that have more complex or unbreakable strings, or options that can be reordered don't work as well in the multi-select component. The multi-select has additional padding and a border - this constrains the available space and decreases the space available for selected options. We have use cases that fall under each of the patterns above.
TL;DR - we might be able to consolidate down to a single component, but we might have to bias towards specific usage patterns which could affect some real use cases we have. I'll keep working on this issue this week and will get some documentation added to the design system assets (multiple-select, labels & pills).
posthog-bot
Bug description
First, there are two very similar looking yet different UX elements on the page, for data attributes and person display names.
The difference is that data attributes are a freeform text input, while person attributes are selected from a fixed list (via the taxonomic filter).
Perhaps we should use just one style for both cases?
Second, the UX for adding data attributes is not so good:
At the very least we shouldn't show the dropdown autocomplete.
Environment
Additional context
Seems to come from https://github.com/posthog/posthog/pull/11253
Thank you for your bug report – we love squashing them!