Improve customizability of search

[raymeskhoury]

This isn't something I need right now since I've hacked around it, but filing as a nice to have. It would be nice if the search box was more customizable. Some things you can't do today without reaching into the internals of the component:

• Focus the search box at the appropriate time. Sometime the search box loses focus and I wanted ctrl+f to refocus it.
• Change the style of the component (e.g. background color, border, etc.)

I mostly like the existing search box and I like that I don't have to reimplement one 😄 but it may eventually be easier just to expose the props and let the client code draw the search box itself.

[jassmith]

I've been thinking about doing this for a bit, basically adding the following API

interface SearchUpdateArgs {
  readonly progress: number; // 0 to 1
  readonly resultCount: number;
  readonly getCurrentResults: () => readonly Item[];
  readonly cancel: () => void;
}

interface SearchProps {
  readonly searchString?: string;
  readonly onSearchUpdate: (args: SearchUpdateArgs) => void;
}

If those two methods are provided, the default search interface will just not show. DataEditorRef already contains a method for jumping to a location, so implementing next/prev would already be possible.

[raymeskhoury]

Yep, something like that would work. If you change searchString, are you guaranteed not to receive any further SearchUpdateArgs for previous searches? I think that would be simpler from a client standpoint. In that case you could also probably avoid having cancel() live on SearchUpdateArgs and just cancel the search when searchString is set to the empty string (or false or something).

If not you would want to know what search the update is associated with.

[jassmith]

I am not sure how much I want to go into 100% assuring that there will be no search update callbacks after changing the search string or not. I can definitely imagine some cases where it would happen. I think the guarantee I can make is as follows:

• Passing a new string cancels the old search
• Once the new search starts sending results, the old cancelled search will not send any results.
• Its possible after setting a string you may receive one more spurious update for the prior search. This is possible due to how the event queue processes with effects.
• If you call cancel on a search, it will 100% absolutely not give any updates after that moment.

It is likely possible to prevent the 3rd point, but Im not sure I want to be responsible for that.

[raymeskhoury]

That sounds fine then - it would be easy to cancel before setting a new search :)

[pzcfg]

We're just looking into adding search now and these proposed improvements sound great to us. 🙂

Just to confirm: by passing in onSearchUpdate and its corresponding getCurrentResults() function, that would let you customize how search results are determined, right?

[pzcfg]

Any chance that customizing results and/or filtering the rows down to just matches are coming soon?

We're currently looking into those additions and right now (as far as I can tell) it looks like we'd have to completely rebuild the search UI and functionality to accomplish this

[jassmith]

ah hmm good point. I will bump the priority. This seems like an obvious use case to enable. You will still have to do some work, but you wont have to re-do the UI.

[fabianTMC]

+1

[jassmith]

This is done