Enhance the Text-Input Group to place chips beneath the toolbar.

[arburka]

In Fleet Management, we plan to expand what inventory can be filtered to include Insights Facts and use the text-input group as our filtering component.

Using the text-input group to filter views allows for faster filtering, can be completed without going back and forth from keyboard to mouse, and can handle more attributes to filter on than the existing name-attribute filter.

When mocking up the flows, we came across a few concerns with keeping the chips inside the input. So, we request that the component be enhanced to allow the filter chips to save below the toolbar (similar to other filters) or save them inside the input (the current way the text-input group works.)

Reasons!

1. The width and other contents on the toolbar dictate the text-input group's length. The length of the component is relevant because it dictates how many chips can be easily seen at once. As the filters become more complex, they become harder to read.
2. Adding chips into the input creates issues when combining this control with other filters on the toolbar. For example, you want to use the text-input group alongside a date range control (something that it wouldn't handle well or something that we want to make more prominent.) In this example, the chips from the control outside the input would add chips to the inside, or the chips would be split across two places and make it difficult to get a complete idea of the filters applied.
3. A similar issue arises when you want to apply a filter that cannot be added from inside the text-input group. A good example here is a Saved Query. The saved query can not be added via the text input, and it would not make sense to add them inside the input. Current designs I have seen from @lboehling, and @mmenestr use a chip in the toolbar to show the applied query.
4. When considering situations like 3 & 4, adding chips below the toolbar allows for a single location that shows everything that affects the current view that accounts for future planned features.
5. With the toolbar's space, we can passively show actions for the view.
6. Chip overflow has to be addressed with the control as it stands anyway. There is no way to see all of the chips, the arrow keys do not move from chip to chip, and the "X more" indicator will disappear periodically.
7. From a quick evaluation by Chris Santiago, a Front End Dev for Fleet, it seems doable to pass the chips from the input to the toolbar. So, it doesn't seem like starting over from square one or completely splitting the control. It would be just a choice of how you would like the output to look.

Mockups:
Exploration of chips "Outside" for Fleet
Exploration of chips "Inside" for Fleet

[mcarrano]

cc @mmenestr Let's discuss.

[mcarrano]

@arburka Thanks for filing this issue. Everything you say here definitely makes sense. The current Attribute-value filter demo under text-input-group is just one example, but not necessarily the best approach in all cases. @mmenestr is currently working on an issue to clarify our filter guidance (patternfly/patternfly-design#1045) so we will include this into the mix.

[nicolethoen]

@mcarrano is this more simply solved by using a Text input group as the search input on a Toolbar? The toolbar can render the applied filters as chips already?

[mcarrano]

Yes, I think so. There's no reason this can't be built today with existing components.

[arburka]

That would be exciting! So we think that we can use the current control and change where the chips are rendered with the existing control?

[nicolethoen]

I think we could wire up a toolbar -such as in this example - with a text input group instead of the multiple dropdowns. Then, instead of the text input group displaying attribute-value pairs as chips in the text input group, it could render them in the chip groups that the toolbar builds.

I could try writing up a quick POC tomorrow.

[nicolethoen]

@mcarrano I played with it some, and I do think the current implementation of Toolbar does limit us a little bit. We would need to make an update to the react implementation (and possibly the core implementation). Right now, you need to have a separate control for each category/chip group. So having multiple chip groups associated with the same control will complicate the component.

The thing that makes the Toolbar so complicated, is the way that it builds its responsive view. It dynamically builds its expandable form at smaller screen widths. it is only able to do that by enforcing some rules like 1 control = 1 chip group. It would take some refactoring to allow this, but with more and more products wanting to use text input groups with attribute/value searches, it is probably an unavoidable enhancement we need to make.

It may will be a complex effort to avoid breaking changes.

[mcarrano]

Thanks @nicolethoen I will add this to the roadmap then. I agree this is something that consumers will likely want to do. Do you think this needs to start in core?

[nicolethoen]

possibly - it may be hard to know until we start evaluating exactly the changes we will need to make to enable this.

[mcarrano]

I am going to transfer this issue to React to get it into a future milestone. Sounds like the solution will be to create a React demo that shows this. If core refactoring is needed, we can open a core issue at that time.

[nicolethoen]

Currently, a Toolbar is wired so that each ToolbarFilter can have only one category of applied filters (chip groups) corresponding to it. This relationship is not flexible enough to allow for a single control (i.e. an attribute-value search) to generate multiple chip groups.

It's possible this is not feasible to simply refactor the toolbar to accommodate this request without introducing breaking changes. But it may be possible to expose the various pieces of a toolbar to allow this variant to be built composably.

This is a snapshot of the desired outcome: