Barista: Поле фильтра 2 — сбор требований

отлично выглядят ребята. у нас уже было несколько требований, находящихся в стадии разработки, о которых мы хотели вам сообщить. Я вижу, что они уже прикрыты здесь

Нас попросили включить И, ИЛИ и НЕ.
Также отключенные состояния, которые вы уже рассматриваете

В ранних макетах визуализировался множественный выбор. Вместо того, чтобы просто получить список предложений и выбрать одно, вы получите те, у которых есть флажки впереди; так что вы можете выбрать несколько из них. Это более простая версия фильтра И, и она лучше, чем вводить один и тот же фильтр (например, страну) несколько раз.

Нас попросили включить И, ИЛИ и НЕ.

Спасибо @subarroca за это, я добавил это в первоначальный список требований.

В ранних макетах визуализировался множественный выбор. Вместо того, чтобы просто получить список предложений и выбрать одно, вы получите те, у которых есть флажки впереди;

Спасибо @danielkaneider за то, что подняли эту тему. Я добавил это в первоначальный список требований.

Для некоторых фильтров может быть огромное количество предложений, например тегов. Было бы неплохо ограничить их N предложениями и отображать «Начните печатать, чтобы увидеть больше», которые будут асинхронно извлекаться, когда пользователь печатает — своего рода поиск на стороне сервера.

Возможно, стоит добавить #78 к требованиям.

Я также рассчитываю на реализацию #78 в Filterfield v2. Фильтры диапазона были бы идеальными для вариантов использования, касающихся фильтрации номера версии (например, 1.194.0).

Я также рассчитываю на реализацию #78 в Filterfield v2.

Абсолютно. Я добавил его в список. Хотя я считаю, что многие из них на самом деле созданы как расширения (то есть не предоставляются самой библиотекой бариста), хорошо иметь все эти варианты использования для расширений, чтобы мы могли определить интерфейс между фильтром и поле v2 и пользовательское расширение лучше.

У нас есть именно тот вариант использования, который описал @Argeath , с множеством тегов для фильтрации в новом представлении проблем. Мы хотим вернуть только подмножество тегов с сервера, соответствующее запросу, который пользователь ввел в поле фильтра. И нам, возможно, даже придется ограничить эти совпадающие результаты, поскольку их может быть слишком много. Таким образом, способ указать «усеченные» результаты также был бы хорош.

Привет, приятно видеть, что вы планируете изменить поле фильтра;)

вариант использования, который у нас есть, немного сложен, и я не знаю, полностью ли его охватывают приведенные выше предложения. Мы хотели бы иметь возможность связывать термины фильтра с логическими соединителями (И, ИЛИ,...)

фе:
показать все для (создатель=userx И серьезность=высокая) ИЛИ (создатель=пользователь И серьезность=низкая)

мы всегда называем это «способом, которым jira позволяет фильтровать задачи».
Я уже видел «множественный выбор для одного типа фильтра» и операторы И/ИЛИ, но можно ли будет определить термины фильтра с помощью скобок (или любым другим способом) и объединить их с логическими операторами?

@petrabrunner К сожалению, я не думаю, что это вариант использования, в частности, для поля фильтра, поскольку это все больше и больше напоминает шаблон языка запросов. Конечно, есть варианты использования и для вашего типа запросов, но я бы постарался не смешивать функциональность языка запросов с полем фильтра.
Может показаться, что приведенный вами пример работает в контексте поля фильтра, но если вы обратитесь к _способу, которым jira позволяет фильтровать задачи_, это может очень быстро усложниться.
TBH, даже логические операторы в поле фильтра, вероятно, являются натяжкой. В настоящее время я пытаюсь выяснить, чего люди ожидают от поля фильтра, если все здесь будет построено или даже возможно, это, вероятно, обсуждение на потом.

Я собираюсь добавить логическую группировку к приведенному выше списку, но имейте в виду, что это может быть очень далеко в списке приоритетов.

@tomheller спасибо за ответ - tbh. Я уже ожидал этого - так как логика будет довольно обширной - но я подумал, что если я не расскажу вам о нашем варианте использования, вы о нем не знаете ;)

Нам также понадобится функция загрузки данных для автозаполнения как частичных. Например, загрузить первые 100 вариантов, а при поиске варианта загрузить отфильтрованные с сервера.

PR для текущей реализации можно увидеть здесь: https://github.com/dynatrace-oss/barista/pull/1021 .

Всем привет, у нас тоже есть пара петиций, отсортированных от большего к меньшему приоритету:

• Возможность установить минимальные и максимальные числовые значения по умолчанию для типов фильтров диапазона.
• Новый тип фильтра: выбор даты.

Спасибо!

Было бы очень здорово поддерживать угловые формы в полях фильтра ;), так проще управлять с точки зрения потребителя. Может быть, разоблачение FilterFormControl для этого поможет

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

```html
formControlName="фильтр"
label="Фильтровать по"
aria-label="Фильтровать по форме"
clearAllLabel="Очистить все"

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

Привет,
Было бы неплохо иметь эту функцию:

Категория по умолчанию: когда пользователь начинает давать чаевые, эта клавиша выбирается. Таким образом, пользователь может пропустить этап выбора ключа. На следующих изображениях вы можете увидеть пример этого, поскольку «Имя» является категорией по умолчанию для фильтрации:

1. Фильтр не сфокусирован:
   
2. Фильтр сфокусирован (пользователь нажал на него):
   
3. Чаевые пользователя:
   
4. Пользователь завершает чаевые:
   
5. Пользователь нажимает клавишу ввода:
   

Привет, команда! У меня есть еще одна петиция, это будет определение:

getTagsForFilterKey (ключ: строка) | DtFilterFieldTag[] | Возвращает массив DtFilterFieldTag со всеми совпадениями, где ключ DtFilterFieldTag содержит параметр key
-- | -- | --

Вкратце: новая версия текущей функции getTagForFilter , чтобы лучше удовлетворять наши потребности.

Как обсуждалось с Маркусом Хеймбахом, он предложил добавить возможность того, что если вы вводите текст изначально и все параметры отфильтрованы, вы все равно можете отправить этот текст как ввод произвольного текста.
Другими словами, свободный текст в дополнение к автозаполнению для корневого уровня.

Как обсуждалось с Маркусом Хеймбахом, он предложил добавить возможность того, что если вы вводите текст изначально и все параметры отфильтрованы, вы все равно можете отправить этот текст как ввод произвольного текста.
Другими словами, свободный текст в дополнение к автозаполнению для корневого уровня.

Но я думаю, что в основном это то, о чем @SaraDavilaMendez уже упоминала в https://github.com/dynatrace-oss/barista/issues/951#issuecomment -686365435.

Как обсуждалось с Маркусом Хеймбахом, он предложил добавить возможность того, что если вы вводите текст изначально и все параметры отфильтрованы, вы все равно можете отправить этот текст как ввод произвольного текста.
Другими словами, свободный текст в дополнение к автозаполнению для корневого уровня.

Но я думаю, что в основном это то, о чем @SaraDavilaMendez уже упоминала в #951 (комментарий)

Спасибо. Пропустил этот комментарий.

Привет!

Мы получили отзывы о другом аспекте, который можно было бы улучшить, а именно о том, как фильтр работает с вводом среднего/длинного текста.

В настоящее время виджет представляет собой входное «окно» размером около 24-25 символов, что немного затрудняет просмотр текста, который вводится или копируется.
Виджет, например, может расширяться и использовать свободное пространство справа, особенно на больших экранах.

Синее поле выделяет размер поля ввода, пример текста: _это умеренно длинный текст_

Перенесено в APM-266067