Dynamic node creation in the Node-RED editor

Hi there,

I've read many comments pointing out that the Node-RED editor is not meant to be dynamic nor should it be doing any computation. I've gone and ignored that because I seem to have made an assumption that Node-RED is a Yahoo Pipes clone, it isn't of course.

I find the editor extremely useful as a mind map tool, Node-RED wasn't meant to be that either but it does a better job than most other mind map tools out there. Plus its easy to extend to make a mind map that actually fits to my mind! In addition to that, my mind map is executable so that I can chain nodes together and generate markdown files from the pathways between nodes. (That I do on the server side.)

For my mind-map, I created the find-all-orphan-nodes node and now I created two nodes to find all pathways between two points in the mind map, I call them seeker and sink (gist link to the code). Basically the seeker traverses all connections (including link-in/out) until it gets to the sink. The seeker then displays twenty-five unique pathways in the tray (the trigger is the oneditprepare callback). This is of course a complete hack and something that no one should be doing at home :slight_smile:

But things just get worse. The other day I discovered Superus and their ChatGPT in 2D space, i.e., they create a concept map using ChatGPT responses. (Aside: the Hacker News discussion on the idea.) I ended up thinking of doing the same using Node-RED but then thought better of it because I have no idea how to create nodes dynamically within the editor. Searching here in the forum, I realised that it wasn't the intention of the editor (dynamic node creation nor computation).

However ... there must be a way! It happens each time that I drag a node-definition from the palette into the workspace, a node is created via the Node-RED APIs. So I assume there a well defined execution path for creating nodes.

My question is this, can someone give me a pointer to the Node-RED codebase where this actually happens? I could try to find the spot myself but I'd like to save myself the time searching through the codebase :wink:

I promise I won't do anything bad with that knowledge!

Thank you for any tips!

Well - adding a node is just inserting it's JSON into the flows file, adding a link is then adding the node_ids into the wires array of the node, and then deploying it (to save it)... of course a) you need to pick what type of node you need, b) set it's x ,y, and z(tab) co-ordinates so that it lays out sensibly, c) assign an ID (so that it can be "wired" into the flow) - and probably a few other things I've forgotten :slight_smile:

1 Like

Or just use the documented API's?

https://nodered.org/docs/api/admin/

https://nodered.org/docs/api/admin/methods/

They affect the server side of things, I would like to do this all in frontend, i.e. in the editor. I don't want to touch the backend ...

Just as an aside: I was thinking about these nodes that I've created, they are a kind of linting:

  • orphans are all nodes that aren't connected, that can't be good unless it's comment nodes
  • seeker and sink are good for finding whether all pathways are realistic, perhaps there are unexpected links that cause issues

In the case of linting, you want to be doing that before you deploy ... so it would make sense to have nodes that only affect the editor. Kind of pre-deploy checks defined as nodes/flows. :thinking:

or ui-template nodes that add things like extra CSS to the <head> of the document

Coordinates, true that is one thing that I don't have when dynamically adding nodes. (0,0) is probably not the optimal placement :wink: z would be the current visible tab ...

Hang on, is the node id perhaps generated on the server side and then passed back to the frontend (i.e. editor)? I know the backend has an id generation for messages ... but is that also used for nodes?

Ok, so there are definitely more reasons for nodes to be without connections :slight_smile:

and indeed config nodes are not "wired" and are not visible in the workspace - but are still nodes...

it's starting to sound like nodes that are connected are in the minority :thinking:

To make it clearer what I mean, I have setup some demonstration flows.

The flows are taken from my Node-RED as Backend project. It's a complete "backend" for a web application (auction platform) providing an API, web-sockets and email sending when particular actions occur.

As example scenario: I want to know which HTTP (aka API) requests sends out a verification email. First I place the seek node at the email of interest, that is shown in the email templates flow (sink node top left). Then I place the seeker node at the front of my router flow (aka url mapping flow) where all HTTP requests come in. When I open the tray for the seeker (right side of flow), I see that three possible pathways lead to the verification email. (One for the signup and two for resending a verification code.)

I find this incredibly useful for finding all usages of a node or pathway that I might not have realised. This is also very useful if a product person would like to know when these emails are sent.

Since these nodes only act within the editor, there is no need to deploy them to the server (and they work in read-only mode). This for me makes them a kind of linting or sanity check before doing a deploy.

This topic was automatically closed 60 days after the last reply. New replies are no longer allowed.