[EuiSearchBar] Using EuiSearchBar's filter w/ keyword fields

[ginkel]

Hi there,

not sure if this is more a question than an issue. I hope that that's still ok.

We're using an EuiSearchBar with a filter:

  const filters: SearchFilterConfig[] = [
    {
      type: 'field_value_selection',
      field: 'state',
      name: 'State',
      multiSelect: 'or',
      options: Object.values(State).map((state) => ({
        value: state,
        view: renderState(state),
      })),
    },
  ]

The query is eventually supposed to end up on Elasticsearch, so we're using EuiSearchBar.Query.toESQuery to transform the Query object into ES query DSL. In the ES mapping, the state field is declared as keyword, which apparently does not work well with the match query that toESQuery creates when doing a multi-select on the filter that creates the following expression in the EuiSearchBar: state:(foo or bar)

That gets translated into the following ES query DSL fragment:

"must": [
  {
    "match": {
      "state": {
        "query": "foo bar",
        "operator": "or"
      }
    }
  }
]

...which in turn does not match due to state being a keyword.

Any ideas how to work around this situation (e.g., by producing a terms query)?

Thanks, Thilo

[github-actions[bot]]

👋 Hey there. This issue hasn't had any activity for 180 days. We'll automatically close it if that trend continues for another week. If you feel this issue is still valid and needs attention please let us know with a comment.

[ginkel]

The issue is still relevant

[cee-chen]

Hi @ginkel - huge apologies that this issue fell through the cracks and that it took us so long for someone to respond to this. Unfortunately most of our devs experienced in ES Query DSL are no longer on the EUI team, so I'm not totally sure if I'll be answering you at all well - stop me if I'm not :)

It would help if you had a minimum reproducible CodeSandbox to exemplify the issue, but from what I'm getting at, it's unlikely we'll prioritize any kind of catch or separate query just for terms that are keywords. We'd likely ask consumers to instead rename their term fields slightly, e.g. state_location instead of state.

However, if you're willing to take a look at our source code that handles the DSL transmogging and are interested in expanding our current code to work around reserved keywords and writing thorough unit tests to ensure no other regressions occur, we'd be super open to accepting PRs on this!

[github-actions[bot]]

👋 Hi there - this issue hasn't had any activity in 6 months. If the EUI team has not explicitly expressed that this is something on our roadmap, it's unlikely that we'll pick this issue up. We would sincerely appreciate a PR/community contribution if this is something that matters to you! If not, and there is no further activity on this issue for another 6 months (i.e. it's stale for over a year), the issue will be auto-closed.

[github-actions[bot]]

❌ Per our previous message, this issue is auto-closing after having been open and inactive for a year. If you strongly feel this is still a high-priority issue, or are interested in contributing, please leave a comment or open a new issue linking to this one for context.