Question: HeaderActionSearch

[ispyinternet]

With on:inputSearch firing per key press, what's the technique to wait until enter key has been pressed to action - this particular key stroke doesn't fire this event.

[ispyinternet]

I wonder if it would be a nice to have to be able to bind a variable to the value too?

[ispyinternet]

I've ended up wrapping in a div and tracking the content in a variable. Feels a bit clunky - would this be the recommendation or any better suggestions?

<script>
let searchString='';
function doSearch(e) {
    if(e.which !== 13) return;
    ...
}
</script>
  <div on:keypress="{doSearch}">
    <HeaderActionSearch on:inputSearch="{e => searchString=e.detail.textInput}"  />
  </div>

[metonym]

We'll take another pass at this component

[ispyinternet]

I guess it would make sense to ensure this and the standalone search were closely aligned?

[metonym]

Yes, as much as possible they should be closely aligned in terms of forwarded/dispatched events (e.g., "on:clear").

[DustinEwan]

It seems to me that this should follow the same API as the Search component.

It would be nice to use this as a fuzzy autocomplete for navigation similar to when you're searching AWS for services (sorry, IBM! I'm not familiar w/ the IBM cloud!)

[metonym]

A new HeaderSearch component for the UI Shell is shipped with v0.24.

Usage
Rendered

---

It would be nice to use this as a fuzzy autocomplete for navigation similar to when you're searching AWS for services (sorry, IBM! I'm not familiar w/ the IBM cloud!)

@DustinEwan I appreciate the sentiment but the HeaderSearch component – like with the regular Carbon Search component – does not contain business logic for searching/filter results. It's left to the user to provide the data to render.

Particularly for global search, I'd imagine that in most cases the results would be served by the backend of an application (i.e. full text search on an extremely high volume of data or data that changes frequently).

[DustinEwan]

@metonym thanks for the follow up, and totally get it. I understand I would need to implement the logic. I guess what I was getting at was that it would be nice to have a list of matches render below the search field, just like a standard autocomplete.

As it stands it seems like that only functionality at the moment is a text input where we need to capture the enter key and display a modal or navigate, etc.,

While I could wrap the HeaderActionSearch into a custom component, I didn't see a nice way of implementing a live updating list of results that feels like an autocomplete just using the components out of the box.

---

Just checked out the new release and the usage demo was exactly what I was looking for, actually.
Great work!