[Feature Request]: Enhance User Experience by Modifying Search Trigger Event in Secondary Header

[fabiomlferreira]

Overview

Currently, the search functionality in the secondary header triggers the search upon the blur event. This behavior might not be as intuitive or user-friendly as it could be.

Proposed Solution
I propose adjusting the default event to initiate the search to be the pressing of the Enter key, with an optional debounce of 1 second.

Example & Additional Context
A great implementation example of this can be seen in the Filament table builder. In their setup, the search typically triggers approximately 1-2 seconds after the user ceases typing, and also activates when the Enter key is pressed.

Suggested Approach
Adopting a similar approach across all input search fields by default would enhance the user experience. While the main search allows us to select this, the secondary header currently does not provide this option. Implementing a consistent search trigger across all search inputs—primary and secondary—would provide a more cohesive and user-friendly experience.

Detailed explanation

No response

Notes

No response

[lrljoe]

Yep, this is actually on the to-do list, along with being able to set custom attributes on each filter input.

I'll leave this open so that people are aware that it's in progress, thanks for a very comprehensive request!

[LemonWipe]

Are there any branches that have this available for testing yet?

[TomThumbsBlues65]

Any updates on this?

[lrljoe]

Can you show me what you're doing to have a search in the secondary header please.

There's a few approaches that you can take, so it'll be easier to help you once I know which approach you're using.

If you're using the "Advanced Example" from the docs, then you can just modify the custom blade that is used there for the secondary header.

If you're using a Filter as a secondary header, then there's some new functionality in the next release that allows you to customise the wire:model behaviour on a per-filter basis:
#1699

Should be released in the next week or so, just need to do some final tests on it, but it's available in the "develop" branch should you wish to play.

[lrljoe]

To give a broader update, there's an imminent release for customising wire:model behaviour for the filters
The global search field has similar logic already, and we are getting steadily closer to all inputs being customisable in terms of how they are wire:model

Version 4 will hopefully just produce a more consistent approach to all config options, as historically, functionality has been bolted on from a number of awesome contributors

Is the real immediate ask here, for a smoother experience to add a field specific secondary header search?
The docs do have the Advanced Example which demonstrates an approach that you can take, but if there's a real appetite for something more built in, then it can get added to the roadmap

[LemonWipe]

I've been using the second header text filters as a means to implement what you are saying for second header search. The behavior configuration changes would be sufficient my intranet's users.

The global search doesn't allow for granularity of filtering multiple fields via a text search kind of way, and I don't think any of my users would assume that it could.

I like the idea of a second header search field, but I wouldn't want to speak for the community and say there's a large demand for it.

[lrljoe]

In that case, give it a week ish, or give the develop branch a whirl, there's some new methods for setting text filters to live/debounce(Xms), blur etc that will be out in the next week or so.