[ZEPPELIN-6533] Apply the notebook search term after the paragraph views exist - #5378
[ZEPPELIN-6533] Apply the notebook search term after the paragraph views exist#5378kimyenac wants to merge 1 commit into
Conversation
…ews exist The `term` query param is read in ngOnInit, which runs before @ViewChildren resolves and before the note arrives over the WebSocket, so a deep-link term was dropped: onParagraphSearch iterated a query list that did not exist yet, and nothing re-applied the term once the paragraphs rendered. Keep the term on the notebook component and (re)apply it in ngAfterViewInit and whenever the paragraph query list changes. The code editor keeps the term too, because Monaco loads asynchronously and would otherwise ignore a term that arrived before the editor was ready. Add a Playwright regression test that opens a notebook with a `term` query param and asserts every occurrence is highlighted.
voidmatcha
left a comment
voidmatcha
left a comment
There was a problem hiding this comment.
The existing Show/hide the code flow leaves a deep-linked search term unapplied when the paragraph editor starts hidden.
editorHide is not introduced by this PR. It is the existing persisted paragraph setting controlled by Show/hide the code; while it is true, NotebookParagraphCodeEditorComponent is not instantiated.
I reproduced the issue in a local Chromium E2E run:
- Hide a paragraph's code editor with Show/hide the code.
- Open the notebook through a URL containing
?term=target. - Show the paragraph's code editor again.
- The editor appears, but the occurrences of
targetare not highlighted.
The search term is initially propagated while the code editor component does not exist, and it is not replayed when that component is created later. Please retain the latest search term at the paragraph boundary and apply it when the code editor becomes available, or add equivalent lifecycle handling. A regression E2E test covering the hidden-then-shown editor flow should be included as well.
Reproduction test and example fix:
voidmatcha@731e1ac
2 participants
What is this PR for?
The notebook component reads the
termquery param inngOnInit, which runs before@ViewChildrenresolves and before the note arrives over the WebSocket. The initial term was applied to a paragraph query list that did not exist yet, and nothing re-applied it once the paragraphs rendered, so opening a note through a?term=...deep link (for example clicking a notebook search result) never highlighted the matching text.This keeps the term on the notebook component and re-applies it in
ngAfterViewInitand whenever the paragraph query list changes. The code editor keeps the term as well, because Monaco loads asynchronously and would otherwise ignore a term that arrived before the editor was ready.The guard suggested in the issue (
listOfNotebookParagraphComponent?.forEach(...)) is already on master, soonParagraphSearchdoes not throw today. The access stays guarded here.What type of PR is it?
Bug Fix
Todos
termdeep linkWhat is the Jira issue?
How should this be tested?
e2e/tests/notebook/search/editor-search.spec.tsgains "highlights the term carried by a deep link when the notebook opens". Run it withnpm run e2e:fast -- tests/notebook/search/editor-search.spec.tsinzeppelin-web-angular. The new test fails on master (0 highlights) and passes with this change; the rest of the spec and the notebook keyboard spec stay green.alpha target beta target gamma targetin a paragraph, then open/#/notebook/<noteId>?term=targetcoming from another page. Every occurrence oftargetis highlighted. The same applies when clicking a result on the notebook search page, which navigates withparagraphandtermquery params.Screenshots (if appropriate)
Before: nothing is highlighted when the note opens through the deep link.
After: the three
targetoccurrences are highlighted.Questions: