I’m looking to customize the default search panel slightly beyond what can be done with pure css.
I think I can hook into almost all of the functions required to execute, and work with, a search query on a view,
e.g. I can create a button and execute the findNext command.
But the one thing I can’t seem to work out is how to actually run the query that highlights all the matches.
I can’t see that this functionality has been exposed via the exports?
Unless I’m missing something.
Indeed, creating and manipulating the search query is currently not exported. What are you trying to do, specifically? Create your own UI panel and use the existing search code to do the rest of the searching?
Yeah - that’s exactly it. I’d like to create my own UI and use the search module to do the work.
As far as I can tell, I don’t need any additional functionality - the search module has it all covered.
Well, since the panel is managed alongside the rest of the search state, and, for example, match highlighting won’t show up unless the panel is open, I don’t think this is as easy as just giving external code access to the query state.
Would being able to pass in your own panel constructor ((view: EditorView) => Panel) plus being able to read and update the query state cover your use case?
I’ve implemented a first version of this in the git repository but I’m waiting to finalize and release it until I’ve had feedback from you.
Yes I think it would - I can have a play with it tomorrow and let you know (I’m +8UTC)
It works really well, there are two additional features I wanted when implementing a custom search panel.
the first time the panel opens the setQuery effect doesn’t fire so I couldn’t catch it in an obvious way. I could see some work arounds but it would be nice if I didn’t need them.
I wanted to be able to catch the toggle effect to do some clean up of the panel elements.
Could you elaborate a bit on the first point? The general idea is that you’d use getSearchQuery when opening the panel to start with the current query, and then in the panel update method, if the query changes while the panel is open, update your form.
For the second issue, would having a destroy method in the Panel interface, which is called when the panel is removed from the DOM, work? That seems more in the style of the rest of the library.
re the first point - it makes sense to call getSearchQuery on first open - I just wasn’t expecting it.
yes a destroy would help.