Filterfield 2 - Requirements gathering

[tomheller]

Since the current implementation of the filter field component lacks a couple of features that have been requested in the past, but are really hard to patch into the current state, we are toying with the idea to create a second version of the filter field. When we started the first implementation of the filter field, a lot of requirements were added after the initial implementation was done, which made it very hard to meet all of them. With this version we want to create the requirements list early to better meet the expectation of the libraries consumer. Please get involved and add to this discussion as we want to be especially thorough to prevent a similar scenario again.

---

Datasource

Possibility to add/set available filters to the datasource of the filter field

It should be easy to define which filters are available, state the filter type, it's children, and validators. In the v1 implementation this is done via a configuration object and the datasource.

Possibility to append available filters to the datasource asynchronously

This is a key feature to load more data based on the users input. This can range from a special word that is filtered for in an autocomplete situation, or the path taken to a special filter. It should be possible to extend the currently available filters as well as load the next filter step. (Refers to #868)

Selected filters (tags)

A selected filter consists of a key, a value, and potentially some metadata that will reflect the tags state.

Tag key and value displays should be customizable

As outlined in #1113, there is a requirement for customizing the displayed key and possible value properties that are shown inside of each individual tag.

Selected filters should be easy to set programmatically

In the v1 implementation the filters can only be set by reference of the elements that were passed top the datasource, which seems quite tedious. (Refers to #473)

https://github.com/dynatrace-oss/barista/blob/fa98ac150b6d324f5c3eaed990c6d6c5f155f318/libs/examples/src/filter-field/filter-field-programmatic-filters-example/filter-field-programmatic-filters-example.ts#L67-L77

It should be easy to change the state of a tag programmatically

It should be easy to change the state of the currently set filters to either editable / disabled / read-only. The current implementation right now requires the consumer to get the currently set filters and find the instance they want to manipulate and add the changes there (refers to #848).

Tags can be editable

It should be possible for the user to go back into an already set filter and edit it's value.

Logical connectors between tags

A recurring request is to add logical connectors, i.e. NOT, AND, and OR to the list of tags. Thank you @subarroca for mentioning this.

Logical groupings

As an extension to the logical connectors between tags, @petrabrunner also mentioned that logically connected tags should be group-able within parentheses.

Uniqueness

Some filters should be removed from the available filters list, if the filter is selected once already by the user.

Filtertypes and extensions

Nesting of filters

Filters should be nestable, to give the user a simple path to filter down to the actual key-value pair. This is reflected in the v1 behavior fairly well.

Select from a set (autocomplete)

This will let the user select a single value from the provided filters. This can be nested until the last filter is selected, i.e. choosing a city gives the user the following filter options: Country > State > Region > City These sets can have a distinct option, meaning that if one of the distinct set is chosen, it is not possible to select another one from the same set. The set should therefore no longer be shown as an option.

Free text with suggestions

Some filters should just be able to hold a free text, defined by the user. The current implementation gives the option to provide a text. There is no indication of what happens how the text is filtered. It might be an idea to add a couple of modes to this type of filter, i.e. startWith, contains, exactMatch. This could give the consumer a little more control over the filtering.

Range

In the v1 implementation the range lets the user choose a single or two values and one of these operators: greater than, less than, equals or range (filtered value should be between first and second provided value). It should be possible to give default values for each field, that is populated in the range. There already have been requests to extend the range to allow Greater than equal and less than equal operators as well. Additionally in a Range operator mode, there should also be the choice for each value to have greater/less or greater/less than. The range could be also considered an extension.

Multiselect

It should be possible for a consumer to add a multi-select (similar to the select from a tag section), but not having a single select, but a multi select setup. As @danielkaneider mentioned this has been in initial mocks of the filter-field and looks quite like a checkbox list in an overlay. (Reference issue #1206) In my opinion this would be something that could also be considered as an extension.

Ranges with custom semantic meaning

This is also highly considered to be built as an extension. Some use cases cover range selections, that do not follow numerical range logic (i.e., version number ranges raised in #78 by @bmrozinski)

Extension to the filters

It should be possible for the consumer to easily provide their own version of a filter and customize the overlay to their needs. Things to consider is to create an interface between the filter field and the extension, so a solid communication between the extension and the filter-field can happen. This would open a lot of possibilities to the consumers to enhance the filter field and trim it to their needs.

Currently considered to be done via an extension (first or third party):

• Range
• Ranges with semantic meaning
• Multiselect
• Datepicker

Validation

Each submitted filter should be able to be validated agains passed validator functions. In the v1 implementation, this was only possible for the free-text type.

Input filtering

When the user is in the process of filling out or selecting a filter, the available filters should be displayed and filtered based on the users input. The v1 implementation already hold this behavior and we would like to keep this.

Support for Angular Forms integration

Based on https://github.com/dynatrace-oss/barista/issues/951#issuecomment-631519841 it should be investigated if an integration with Angular Forms will be doable (filter field values can be quite complex). But this is definitely something to look into.

[OFouda]

looks great guys. we already had a couple of requirements coming in the pipeline that we wanted to reach out to you about. I see they are already covered here

[subarroca]

We've been asked to include AND, OR and NOT. Also disabled states, which you're already considering

[danielkaneider]

Early mocks had a multi-selection visualized. Instead of just getting a list of suggestions and selecting one, you would get those with checkboxes in front; so you could selected multiples of them. It's a simpler version of the AND filter, and nicer than entering the same filter (eg. country) multiple times

[tomheller]

We've been asked to include AND, OR and NOT.

Thanks @subarroca for bringing this up, I have added this to the original list of requirements.

Early mocks had a multi-selection visualized. Instead of just getting a list of suggestions and selecting one, you would get those with checkboxes in front;

Thanks @danielkaneider for bringing this up. I have added this to the original list of requirements.

[Argeath]

For some filters there may be a huge amount of suggestions, e.g. tags. It'd be nice to limit them to N suggestions and display "Start typing to see more" that'd be asynchronously fetched when user is typing - kind of server-side searching.

Maybe it'd be worth to add #78 to requirements.

[bmrozinski]

I'm also counting on #78 implementation in Filterfield v2. Range filters would be perfect for use cases regarding version number (eg. 1.194.0) filtering.

[tomheller]

I'm also counting on #78 implementation in Filterfield v2.

Absolutely. I've added it to the list. Although I consider a lot of these to be actually built as an extension (meaning not provided by the barista library itself), it is good to have all these use cases for extensions present as well, for us to define the interface between the filter-field v2 and a custom extension better.

[christian-fischer]

We have exactly the use case that @Argeath described, with lots of tags for filtering in the new problems view. We only want to return a subset of tags from the server, matching the query that the user entered in the filter field. And we might even have to limit those matching results as there might be too many. So a way to indicate "truncated" results would be also nice.

[petrabrunner]

Hi, great to see that you plan to give the filterfield a makeover ;)

the usecase that we have is a bit complex, and I dont know if the suggestions above already cover it completely. We would love to be able to chain filterterms with logical-connectors (AND, OR,...)

f.e.: show all for (creator=userx AND severity=high) OR (creator=usery AND severity=low)

we always refer to it as "the way jira lets you filter for issues". I have already seen the "multiple-selections for one filter-type" and the AND/OR statements - but will it be possible to define filter-terms with brackets (or any other way) and combine them with logic-operators?

[tomheller]

@petrabrunner Unfortunately I don't think that this is a usecase for the filter field in particular, as this resembles more and more a query language pattern. There sure are usecases for your type of queries as well, but I would try not to mix query-language functionality with the filter field. The example given by you may seem to work in a filter field context, but if you refer to the way jira lets you filter issues, this can get more complex very fast. TBH, even the logical operators in the filter field are probably a stretch to this. Currently I'm trying to figure out what people would expect from the filterfield, if everything here will be built or is even feasible is probably a discussion for later.

I'm going to add logical grouping to the above list, but please be aware that this might be very far down the list of priorities.

[petrabrunner]

@tomheller thx for the reply - tbh. I already expected this - as the logic would be quite extensive - but I figured, if I dont tell you about our usecase you dont know about it ;)

[thomaspink]

We would also need the feature of loading data for autocompletes as partials. E.g. load the first 100 options and when searching for an option load the filtered ones from the server.

The PR for the current implementation can be seen here: https://github.com/dynatrace-oss/barista/pull/1021

[airime]

Hello everyone, we have a couple of petitions too, sorted from more to less prioritary:

• The ability to set default minimum and maximum numeric values for range filter types.
• A new filter type: the date picker.

Thanks!

[rarenal]

It would be really cool to support angular forms in the filter fields ;), so it's easier to manage from the consumer point. Maybe exposing a FilterFormControl for it would help

  interface FilterFormControl {
    field: string;
    value: FilterValue // any basically
    operator?: 'AND' | 'OR' | 'NOT'
    ...
  }  

<dt-filter-field
  formControlName="filter"
  label="Filter by"
  aria-label="Filter By form control"
  clearAllLabel="Clear all"
></dt-filter-field>

// comes from a saved config
initFilters = [{
  field: 'foo',
  value: 'bar'
}];
form: FormGroup({
  filter: new FormControl(initFilters)
});

[SaraDavilaMendez]

Hi, It will be nice to have this feature as well:

Default category: when the user starts tipping this key is selected. By doing so the user can skip the step of having to select the key. In the following images you can see an example of it, being 'Name' the default category to filter by:

1. Filter not focused:
2. Filter focused (user clicked on it):
3. User tipping:
4. User finishes tipping:
5. User press enter key:

[airime]

Hello team! I have another petition as well, this would be the definition:

getTagsForFilterKey(key: string)	DtFilterFieldTag[]	Returns an array of DtFilterFieldTag with all matches where the key of the DtFilterFieldTag contains the key parameter

TL;DR: A new version of the current getTagForFilter function, to better fulfill our needs.

[thomaspink]

As discussed with Markus Heimbach, he proposed to add the possibility that if you type initially and all options are filtered out you still can submit this text as a free-text input. In other words, a free-text in addition to the autocomplete for the root level.

[esukram]

As discussed with Markus Heimbach, he proposed to add the possibility that if you type initially and all options are filtered out you still can submit this text as a free-text input. In other words, a free-text in addition to the autocomplete for the root level.

But I think, that is basically, what @SaraDavilaMendez already mentioned with https://github.com/dynatrace-oss/barista/issues/951#issuecomment-686365435

[thomaspink]

As discussed with Markus Heimbach, he proposed to add the possibility that if you type initially and all options are filtered out you still can submit this text as a free-text input. In other words, a free-text in addition to the autocomplete for the root level.

But I think, that is basically, what @SaraDavilaMendez already mentioned with #951 (comment)

Thank you. Did miss this comment.

[giordy]

Hello!

We received some feedback on another aspect that could be improved, namely how the filter deals with medium/long text input.

Currently the widget presents an input "window" of about 24-25 characters that makes it a bit difficult to review the text that one inputs or copy-pastes. The widget for example could expand and make use of the free space on its right side, especially on large screens.

The blue box highlights the size of the input box, the example text is: this is a moderately long text

[lukasholzer]

Moved to APM-266067