[web-console] Implement search bar for logs tab#6394
Conversation
Unify logs implementation across pipeline page, profiler page and the standalone profiler app Signed-off-by: Karakatiza666 <bulakh.96@gmail.com>
|
No screenshots? |
| @@ -0,0 +1,244 @@ | |||
| <script lang="ts"> | |||
There was a problem hiding this comment.
Isn't it customary to have a file-level comment explaining what is in the file?
| issueCategoryFilter: string | ||
| /** Links the metrics node title back to (searches for) the node in the diagram. */ | ||
| onSearchNode?: (query: string) => void | ||
| /** Focus the analysis-panel search input. Invoked from inside a tab (e.g. the log list |
There was a problem hiding this comment.
You are documenting an API, but the description says how the API is used by an implementation. Wouldn't this comment belong in the implementation?
| let lookupQuery = $state('') | ||
| // Bound to the shared analysis-panel lookup <input>. Tabs (e.g. the log list) can request | ||
| // focus via the `onSearchShortcut` callback threaded through `analysisTabProps`. | ||
| let lookupInputEl: HTMLInputElement | undefined = $state() |
There was a problem hiding this comment.
then why not name it analysisPanelElement?
| onSearchShortcut | ||
| }: { | ||
| logs: { rows: string[]; totalSkippedBytes: number; firstRowIndex: number } | ||
| /** Current search; the host advances `occurrenceIndex` (wraps modulo match count) and |
There was a problem hiding this comment.
where is occurenceIndex?
| observeContentElement: (e) => e.firstElementChild! | ||
| }) | ||
| let virtualizer: VirtualizerHandle = $state()! | ||
| // Streaming-log rows from the manager already carry trailing newlines, so the default |
There was a problem hiding this comment.
this comment should be on the join statement, and it can be much shorter
| * highlight anything" — keeps callers free of empty-query / bad-regex branching. */ | ||
| export type LineMatcher = ((line: string) => boolean) | null | ||
|
|
||
| export function compileSearchPattern(pattern: SearchPattern): LineMatcher { |
There was a problem hiding this comment.
could all this search infra be reused for other components like the profiler?
Then maybe it should not be called "logSearch"
| export function findMatchOffsets( | ||
| line: string, | ||
| pattern: SearchPattern | ||
| ): Array<readonly [number, number]> { |
There was a problem hiding this comment.
how about defining a type instead of using a list of numbers?
| } | ||
| // Walk text nodes once, recording each one's [start, end) span in the element's flattened | ||
| // text. Looking up a Range endpoint is then a linear scan over this list — cheap, given | ||
| // we only do it for a handful of matches on a single line. |
There was a problem hiding this comment.
cheap for a fixed log content, but the log content may refresh too
| // we only do it for a handful of matches on a single line. | ||
| const spans: Array<{ node: Text; start: number; end: number }> = [] | ||
| const walker = document.createTreeWalker(el, NodeFilter.SHOW_TEXT) | ||
| let cum = 0 |
| * No-op (silently clears) on browsers that don't expose `CSS.highlights` or the global | ||
| * `Highlight` constructor (older Safari/Firefox). | ||
| */ | ||
| export function applySearchHighlight( |
There was a problem hiding this comment.
I hope this is robust, some tests for it could be useful
Unify logs implementation across pipeline page, profiler page and the standalone profiler app
Testing: manual, added unit test
Screencast.from.2026-06-04.21-16-25.webm