A general appeal: if you see something that is clearly not right with v5, please go straight to raising an issue. Adding more and more to this topic doesn't help us keep track of things.
Sorry I post here first to ensure that it hasn't be raised before - or perhaps it's not a bug, i.e. the scroll query above is known and wanted.
Now I've got another but that's a bug and I'll post it over at GH.
You can check the issue list to see if it has been raised before. Particularly if you see something specific to a new NR5 feature. It may have been mentioned in the forum, but if it hasn't got to an issue yet, then raising one will help. Otherwise I send Monday morning scanning through all the replies trying to pick out what needs raising and could easily miss something.
I mean you could do that on Sunday evening to prevent yourself from doing it on Monday 
/s
So to summaries - from me:
- scrollbars not being updated on jumping through nodes - issue or no issue?
- resize event not being passed to search popover - that's an issue, I'll create
- "0 plugins" - I'll leave that to GogoVega to decide what to do there.
- navigation overlapping nodes at edges - issue or no issue?
- With the left hand sidebar visible, edit a function, open the extended editor. It overlays the sidebar - can confirm that happes, fix is to resize the function editor - issue or no issue?
the rest are already issues.
Raise them all as issues. 1/2/3 are all incorrect behaviours. 4/5 are a bit more subjective but let's have an issue for each if them for future reference.
The other part here is that people looking to contribute fixes aren't going to trawl the forum. Having issues on GitHub gives them something to browse through and see if they want to help tackle.
Ok all done, I've left number 5 for @jbudd to create an issue for, wasn't my find after all but I can confirm it.
Hello @knolleary @dceejay wouldn't targetting esbuild and quemu solve this issue of docker without changing anything... Wow, connecting to this forum seems like congratulating kids going to college 
, can't believe it almost a decade now ... I regret due to huge restriction of banking culture , I can not contribute to modules and flows .. but so far , I am now using esbuild instead of emscripten .. and I think everyone that want to produce a container shouldn't ship anything that is not compiled anyway... Marcus got same conclusion and created a repo for node-red-sfe , clement created node-red dxp ... so tehnically we are all converged to a general target that node-red will remain the de facto swiss knife tool and in front of prod tool chain. I will looks at the v5 with great interest
1 Like
I fully agree but if I see strange behaviour, especially if I can't pin down an exact sequence to reproduce it, I will raise it in the forum to see if others also see it.
#5 is not subjective, it is a bug. But it only takes 10 seconds to reproduce. Did you try it before classifying it?
In this instance, since Nick asks me to, I'll raise a Github issue. It won't be very easy, I'll have to search which repository to raise it against. node-red? @node-red? Node-red-admin? node-red-nodes?
https://github.com/node-red/node-red/issues/5812
But Nick has already expressed the opinion that it's subjective, so I have no expectation of it being fixed.
Incidentally: I have 3 issues with the Monaco editor specifically in v5 which combine to make it almost unusable.
I can't believe everyone has the same experience or the forum would be humming.
I'm planning to revert to v4. If I run the installer specifying v4.1.11, will it do a complete reinstall including Monaco?
That's was based on a quick read and I may be missing something. If you think it's definitely a bug, then raising it is the right answer and we can triage it properly.
Are they the ones already raised in GitHub? If not, please let us know.
Monaco is built into Node-RED. Downgrading to NR4 will get you the version of Monaco built into NR4.
Well two are on github. The third is so bizarre (click in the editor and start typing, the first character is not inserted) as well as intermittent, but frequent, that I can't believe it's not my fingers.
However it seems to be confined to NR5 - I went back to 4.1.11 and so far it has not recurred.
I did raise it in the forum Issues-with-monaco-editor - item 2 and nobody has said "Me too".
So far unable to see this. First character added to editor as expected
1 Like
@jbudd just to followup on the sidebar resizing issue - I now understand what was being reported and it is definitely a bug; nothing subjective about it and we'll get it fixed.
4 Likes
Is it just me or is the drag and drop behaviour in the sidebars superconfusing or just bugged ?
In the left sidebar I see 'explorer' and 'palette'.
- when i drag 'explorer' to the placeholder of the palette
- it shows 2 placeholder positions while dragging
- when i let go, the palette disappears !?
- only 1 position remains with the explorer taking the full sidebar.
- when i drag again, 2 placeholder positions are shown again and when i let go the palette shows again
I am not following the idea behind this behaviour. I would expect them to 'switch' positions.
Hi @bakman2, thanks for the feedback. There are four 'slots' where the sidebar panels can be placed. You can stack up multiple panels in each slot and then toggle between them via the buttons in the toolbar. Moving a panel from one slot to another does not swap them - it adds the dragged panel to the stack of panels in the target slot.
If you empty a slot, then the other slot on that side of the editor expands to fill the space rather than leave an empty gap. When you start dragging a panel from this point, the editor shows placeholders for all four slots (including the empty one).
With that model in mind, I believe the behaviours are consistent.
I can understand your view about swapping panels. That doesn't work easily with the stack model I've described.
Thanks, I am afraid this behaviour will never actually 'click' in my mind. I find it very confusing, but managed to set it up the way I wanted.
Just a small UX observation: when both the node and its status indicator are highlighted in blue,
I think it makes the selection feel a bit less clear. Personally, I think it would feel a bit cleaner if only the node itself was highlighted. Not a big deal, just some feedback after using it for a while.
1 Like
The reason is the extra spacing between blue highlight and node which makes the highlight more obvious, IMHO.
NR4 has no spacing (orange highlight and node) so there is more distance between the status and highlight:
Remove the spacing and the highlight becomes harder to notice, increase the distance between status and the node and the association between status and node is harder to comprehend when there is no highlight.
Potential solution would be to have a dynamic gap between status and node - the spacing increases when node is highlighted and reduced when not. That would produce extra "flickering" when nodes are dehighlighted/highlighted (think search results for example).
Another solution would be extend the blue highlight to encompass an empty status line, i.e., all nodes are highlighted as if they had a status value. That would provide consistency but would visually be very confusing (i.e. why the extra spacing?).
I'm just thinking aloud because I also noticed this and am unsure whether I find it good or bad. I've gotten used to it because the blue highlight with the spacing to the node is clearer to identify on the workspace:
versus:
I think the blue highlight works better with "busy" nodes that have many things going on.
I think that this is a change since NR4. If I attempt to import a flow with node types that are not installed I see
There does not seem to be a way to escape out of that without going to Manage Modules. This is a very common requirement when importing flows from the forum. I often want to just look at the flow without installing the nodes.
1 Like
I agree that it looks slightly odd but also agree that overall, it is for the best. As you say, it is much clearer.
