SearchBar Event Behaviour

[GCHQDeveloper9438576290438652]

Summary of the bug

I am using the Search Bar: https://design.sis.gov.uk/components/search-bar/code within a React 18 application. We want to prevent searching unless the user has entered a valid search query (ideally disabling controls until a valid query is entered).

However while the search bar gives a few validation methods they don't meet our needs

🪜 How to reproduce

We have embedded a component in this way:

<IcSearchBar
        id={SEARCH_BAR_ID}
        charactersUntilSuggestion={2}
        disableFilter={true}
        fullWidth
        label="Basic Search Bar"
        hideLabel={true}
        onIcSubmitSearch={() => {
          handleSearchSubmit();
        }}
        placeholder={SEARCH_PLACEHOLDER_TEXT}
        value={searchQuery}
      />

Reading the documentation the logic approach would be to add a function to the onIcChange or onIcInput events which captures the input and sets a state to flag if the control should be disabled (e.g. the disable property).

The issue is if you do this the state change triggers a redraw of the control and you either have to manage the value externally (which gets problomatic) or use the debounce property. We've found debounce depends largely on the customer machine and so getting it to reliable work is impossible.

It would be really nice if there was a property where we could pass in a function to validate the data within the control (returning true/false or throwing an exception if there is an error). That way custom validation rules could be added as needed.

[github-actions[bot]]

Welcome 👋

Welcome to the ic-design-system repo, thank you for raising an issue!

How to contribute

Please read our CONTRIBUTING.md, which explains our ways of working and guidelines for contributions.

Code of Conduct

We'd appreciate it if you could read and abide by our Code of Conduct, as we wish to foster an inclusive and respectful community.

[GCHQDeveloper9438576290438652]

Just to add what we really want to add is a function a bit like this:

`export const Example Page: FC<> = () => {
  cosnt { isDisabled, setDisabled } = useState<boolean>(false);
  
   const setIfDisabled = (event ) => {
   let disableSearch = false;
   //example validation check, we have more complex stuff
    if (event.detail == 'bob') {
      disableSearch =true
    }
    setDisabled(disableSearch)
  }

  return (
    <IcSearchBar
        id={SEARCH_BAR_ID}
        charactersUntilSuggestion={2}
        disableFilter={true}
        fullWidth
        label="Basic Search Bar"
        hideLabel={true}
        onIcInput={setIfDisabled()}
        disable={isDisabled}
        onIcSubmitSearch={handleSearchSubmit()}
        placeholder={SEARCH_PLACEHOLDER_TEXT}
        value={searchQuery}
      />
  );
}

[MI6-255]

Design will review if this is a good pattern, as disabling a button may cause confusion. Moving to design to explore if there is a good pattern we can implement for this

[MI6-255]

Development need to know what the design decision is for this

[gd2910]

Hi @stephen51611 and thanks for raising an issue. I think I understand what you need but I may need more information.

So far though I'd veer against disabling controls on IcSearchBar in favour of user feedback and handling the data before it is sent/submitted, I've put together a stackBlitz as a rough example.

We don't currently have the option to disable the control, so any use of the disabled prop would render the search unusable (if an incorrect search term were typed, it would disable all input).

If the search options are known perhaps a searchable IsSelect would fit your use case? IcSelect has the advantage of more robust validation options, and filtered options would validate search terms from the user.

Without comprehensive feedback to the user around searching for a 'correct' option, I'd worry it would be difficult for a user with accessibility issues to navigate a component with disabled controls.

Please let us know if this is of any help, or if not please provide more information regarding the use-case.