Reset filters to initial state on setSearchTerm

[marcvangend]

When a search term is set, the filters are cleared by default. This usually makes sense and most search interfaces on the web behave the same. However, in a setup where initialState is used, I would expect that setSearchTerm restores the initial filters, similar to what reset does.

My personal use-case is a site with multilingual content. The search results are initially filtered by the active site language, but users can change the language filter to show other languages too. Currently, the setSearchTerm action clears the language filter. Instead, I need (and expected) Search UI to restore the initial language filter.

Proposed solution
Either of these two options:

1. Change the behavior of the shouldClearFilters option to restore initial filters if there are any.
2. Add a new option to setSearchTerm, eg. shouldResetFilters, to reset filters to the initial state.

[JasonStoltz]

Great use case, and sorry to hear that you're struggling with this.

I had another thought, which is to add an option to individual filters which determines whether or not they'll be removed on a new query.

I thought to use the term "sticky", though we could call it something else instead.

[marcvangend]

Thanks for the quick reply.

I like the idea of a sticky filter. If I understand correctly, combined with a language filter in initialState the result would be that:

1. the default language filter is enabled when someone first loads the search page
2. setting a search term will not unset the language filter
3. after the language filter has been changed by the user, it will keep its value when a search term is entered

For my use case that would work well, it might even be more user friendly than my proposed solution.

[marcvangend]

By the way, if anyone is interested, my current suboptimal workaround is to wrap the SearchBox with a custom component:

import React from 'react';
import { SearchBox, withSearch } from '@elastic/react-search-ui';

/**
 * IMHO, restoring the initial filters should not be the responsibility of the
 * search box, but rather the setSearchTerm action. This component wraps the
 * default SearchBox component as a workaround.
 */
function SearchBoxWithInitialFilters({
  setSearchTerm,
  reset,
  ...props
}) {
  const submitHandler = searchTerm => {
    reset();
    setSearchTerm(searchTerm, {
      shouldClearFilters: false,
    });
  };

  return <SearchBox {...props} onSubmit={submitHandler} />;
}

export default withSearch(({ setSearchTerm, reset }) => ({
  setSearchTerm,
  reset,
}))(SearchBoxWithInitialFilters);

[joemcelroy]

another concept is with baseFilters which are applied to the search but hidden from the UI. BaseFilters will remain even when reseting the search. Would that work here?

[marcvangend]

another concept is with baseFilters which are applied to the search but hidden from the UI. BaseFilters will remain even when reseting the search. Would that work here?

I guess you mean what is called "global filters" in the advanced readme? In fact I also use those in the same project, so users can search within a section of the site. But it is not what this issue is about.

[joemcelroy]

OK - I made the assumption that the language option is outside of the search app and changed across the app by the customer, like a language selector for a site. The suggestion made assumption that the customer's language change affects more than just search and you apply the global filter behind the scenes.

You have language as a Facet and you want these filters (belonging to a language field) to have some sort of flag to be preserved and cannot be removed by other components except within the language facet component itself and the filters remain preserved even when the search is reseted.

I would say this type of request is pretty niche. Maybe we could provide an escape hatch in a form of a hook for the reset method where it allows you to handle the reset call?

   const myCustomResetHandler = (beforeSearchState, afterSearchState) => {
      const languageFilters = beforeSearchState.filters.find((filter) => filter.field === "language")
      return {
         ...afterSearchState,
         filters: [languageFilters]
      }
  }

[marcvangend]

Indeed my project is not your average multilingual site. In short, it is a publishing platform where a limited number of languages is available for the interface (navigation, forms, etc.), but editors can publish articles in dozens of other languages too.

But anyway, it's not just about my project. I can imagine it's not a feature that many would need. On the other hand, several people have expressed their interest in the Sticky Filters (#89) @JasonStoltz mentioned, so I'm not alone either.

The custom reset handler you propose seems like a potentially very flexible solution. I guess that would be another option on the SearchProvider config? Anyway, it would be good if this logic is not closely tied to the SearchBox component, as it is in my workaround code above.

[joemcelroy]

yeh this will be central to the Search UI state management and could morph into something wider like a hook between all search state transitions, not just reset. Within this function you can detect if the filter is not present in the afterSearchState and update the searchState accordingly to your business logic.

Im just hesitant on implementing such a feature as its tough to preserve a particular set of filters and be allowed to be removed depending on where the state change is being called from. State change / filters would need to have some sort of context of where it was called from to take into account whether it can remove the filter. This can be a very "sticky" situation (pun intended) 😂

[sphilipse]

@yansavitski consider for your Search UI epic