Convert CSV to use document searcher #5937
Conversation
|
Turns out this was a little harder than we thought, because we forgot to actually provide a search provider registry to the system! So I corrected that as well, so this was a really good test case of something extending the search system. |
|
CC @aschlaep |
There was a problem hiding this comment.
Thanks @jasongrout. I have a few comments/questions, some about the CSV search, and some about the general API and structuring of the search extension.
Two main structure questions:
- Why does this not use the
*/*-extensionpattern? I know it can be a bit annoying to split them out, but it is kind of out-of-step with the rest of the monorepo structure. - In a number of places there are
instanceofchecks andanytypings. Those make me nervous, and I wonder if we could tighten them up a bit.
| * @param widget - The widget to search over. | ||
| * @returns the search provider, or undefined if none exists. | ||
| */ | ||
| getProviderForWidget(widget: any): ISearchProvider | undefined; |
There was a problem hiding this comment.
Why is this typed as any? The name seems to suggest Widget
| } else if (domain) { | ||
| this._cm = domain.content.editor; | ||
| async startQuery(query: RegExp, searchTarget: any): Promise<ISearchMatch[]> { | ||
| if (searchTarget instanceof CodeMirrorEditor) { |
There was a problem hiding this comment.
It's not really the point of this PR, but this logic looks fragile to me.
| scrollY += this._grid.sectionSize('row', i); | ||
| } | ||
| for (let j = scrollX; j < this._column - 1; j++) { | ||
| for (let j = scrollX; j < col - 1; j++) { | ||
| scrollX += this._grid.sectionSize('column', j); | ||
| } | ||
| this._grid.scrollTo(scrollX, scrollY); |
There was a problem hiding this comment.
The scrolling into view doesn't seem to be working in my testing.
There was a problem hiding this comment.
Great, thanks for pointing it out.
| // check to see if the CMSearchProvider can search on the | ||
| // first cell, false indicates another editor is present | ||
| return ( | ||
| domain instanceof DocumentWidget && domain.content instanceof CSVViewer |
There was a problem hiding this comment.
In other places in the codebase we would do a check on an InstanceTracker, which seems safer and more idiomatic. Is there a reason for the instanceof checks instead?
There was a problem hiding this comment.
The tracker won't work here because the csv viewer doesn't expose a tracker. Granted that's a problem with the csv viewer, but I was trying to limit scope here in this PR.
| if (cellData.indexOf(searchText) !== -1) { | ||
| const increment = reverse ? -1 : 1; | ||
| this._column += increment; | ||
| for ( |
There was a problem hiding this comment.
How does this perform on a large CSV? Is there any danger of this hanging?
There was a problem hiding this comment.
Good question. I left the searching logic basically alone, so it probably performs on par with what it was before (with the exception that now I do a regex match instead of a string lookup).
|
@ian-r-rose - excellent questions. Our premise on this was that it is a first cut of the functionality, and there will be cleanup and iteration of this going forward before 1.0. To the specific questions: we plan to refactor into two plugins, like we have elsewhere, and I also want to tighten up the typings like you mention. |
|
WIP - I'm going ahead and splitting the package in this PR. |
jasongrout
changed the title
|
Sounds good @jasongrout. I think it's reasonable to get this out the door, then do some tightening later. Let me know when you think it's ready. |
jasongrout
changed the title
There was a problem hiding this comment.
Works great! Thanks for the additional restructuring @jasongrout.
lock
bot
added
the
status:resolved-locked
Also, remove the Edit Find menu delegator, preferring instead the document search UX.
See #5523 where the CSV find functionality was originally implemented.