New editor event when all nodes have been loaded

Hi folks,

Every time I need to develop a sidebar panel in the flow editor, I am struggling to initialize its content. Because the html content of the sidebar panel is being constructed in the onpaletteadd event (of the corresponding config node). But that event happens rather soon, so at that moment no nodes have been loaded yet into the editor. And I need information about those nodes to construct the content of my sidebar panel...

When I add this line of code to the nodes.js file:


Then I can easily listen for that event, and get access to all nodes in the event handler:"workspace:loaded", function(node) {
    RED.nodes.eachConfig(function(configNode) {
          // Now all the nodes are loaded...

Is it ok to create a pull request to emit this event, and to update the Editor API documentation?

Thanks !!!


How does your sidebar handle nodes being added and removed while the user is editing the flows?

Do you need to keep it up to date as the flows are edited?

If so, it would be better to listen for the nodes:add and related events to keep your sidebar in sync.

1 Like

Hi Nick,

I indeed should have mentioned that. In this case I am only interested in nodes that have been deployed on the server. Nodes that are being added to the editor are not interesting for me, but as soon as they are deployed they become important. From then on they should appear in my sidebar, so the user can communicate with the server-side counterparts of the deployed nodes (via their representation on the sidebar panel).

So it would be nice if I could update the content of my sidebar panel:

  1. Initially when the flow editor imports all deployed nodes from the server (via the above new event).
  2. At every deploy, via the 'deploy' editor event.
1 Like

Perhaps the description of the particular use case will make it more clear.

It is a sidebar panel for the FlexDash dashboard from @tve. You can create multiple FlexDash config nodes. As soon a such a config node is being deployed, it becomes a real FlexDash dashboard instance on the server. By visualizing those deployed config nodes in the sidebar panel, you get in fact a list of running dashboards. That way the user can start interacting with all his running dashboards via the sidebar panel. For example rebuild a dashboard, or show the logs, or ...

1 Like

Something that is difficult to do just with add&remove events is to maintain a persisted list of dependent nodes. For example, a UI tab might need a list of the panels it contains. This is different from .users if there is some per-dependent info or if the order matters. The problem with just add/remove is that it's impossible to prune non-existent dependents from the list. For example, on import, some of the dependent nodes may not have been imported.