Highlight nodes in search results list

Core Development
1

Hi There,

I really enjoy the search functionality but one thing that irritates me is that I sometimes don't know which node is meant - since I can't remember which node I've already opened.

What I would like is that nodes are highlighted (see blinking border) when I move the mouse over the search result:

node-highlight-search3

This screencast is particularly pertinent because all nodes are called "template" (the connected nodes make the context clear).

To get this working, all I did was add these lines:

div.on("mouseover", function(evt) {
    if ( node.z == RED.workspaces.active() ) {
       RED.view.reveal(node.id)
    }
});

here.

I explicitly don't change workspaces (to avoid confusion) by checking the 'z' property.

Is there general interest in this?

2 Likes
2

What happens if the search results are on different tabs ?

3

Nothing. No highlight, no switching of tabs.

That’s the current behaviour so there’s no change.

Hence this works best in conjunction with flow:current.

1 Like
4

Yes, please!

So does the editor window underneath the search box shift around when a node is revealed that is outside the visible bounds of the viewport? Or worse, it's hidden behind the current Search results list? I find the revealed location to be somewhat random, so that might need some thought, too.

There are several things that would make the search more usable, imo. For instance, how can I search only for nodes that are enabled? I suspect there may be a way, but if I have 10 matches and only 2 are enabled, the disabled nodes should show up dotted in the search results (i.e. the same styling the editor uses), ideally at the end of the list.

Autocomplete for things like type:template would be nice to have, so we don't have to type the entire name.

And if I don't select any filters (e.g. "current flow") showing the ones on the current tab at the top of the search results would be most welcome.

3 Likes
5

And perhaps remove the gray overlay as well, not sure what it adds.

6

because while the search dialog is open, you can't (and shouldn't) interact with the flow - which makes sense since the search content is a snapshot of your current flow --> changing the flow would invalid that snapshot.

7

When clicking off the panel, it should hide it, just like vscode for example.

8

??? it does do that

Screen Recording 2025-11-25 at 10.41.03

9

If only all editor popups behaved alike ...

10

Thats my point, there is no reason for the gray overlay

11

I sense a circle starting up here - that was my point: the point of the overlay is that "don't modify the flow, I'm just searching it" - the grey overlay communicates that to the user. else it would be even more confusing.

it's a communication element to the user: you are now searching this flow, you can't modify the flow while searching. fullstop. there isn't a search and modify feature in NR.

And the click-out-and-disappear pattern is used for the editor and other panels, so this is a very Node-RED thing to be doing. Instead of a confirmation: "are you sure you want to exit the search?" dialog.

now: don't come and say "well the editor panel doesn't have a grey overlay when it's open" - no it doesn't but the plugins that aren't usable when the editor is open do! I guess there is a case to be made for removing the grey overly for search if the flow does become interactive (i.e. node highlights)....

I think I just went in a circle ....

EDIT: i guess I was off-base: the edit panel also activates the grey overlay - so it is consistent behaviour. crazy how this never really occurred to me.

12

Not really, this is how UI's should work! So intuitive that you don't notice. :smiley:

1 Like