How can i make a singleton node

Developing Nodes
1

Just imagine for a second you were trying to create a singleton-node for managing some http-context-specific "global state", why cant you throw an error in a constructing function to prevent the node vom initializing?

just take this code as an example(ts):

const nodeInit: NodeInitializer = (RED): void => {
    function BaseNodeNodeConstructor(
      this: Node,
      config: NodeDef
    ): void {
      //just for testing
      throw new Error("i hope i cant create this node");
    }
    RED.nodes.registerType("test-node", BaseNodeNodeConstructor);
  };
  
  export = nodeInit;

i defined the custom node to throw an error as a test, the error shows up in the console:
grafik

and for some reason the node still registers in the flow-editor...

is there any other way enforcing a node being a singleton?

2

Porobably because Node-RED tries very hard not to crash?

I think so, though I've not actually tried. It isn't, of course, the "normal" operating mode.

You could try to put a trap in the Editor to prevent users from creating another node. In UIBUILDER for example, I have some code that monitors the node add/change/remove events:

image
image721×295 15.1 KB

You could use something similar to prevent creation of a new instance of a node. I use it to make sure that no two uibuilder nodes have the same url.

3

The editor doesn't provide a way to enforce this type of constraint - it isn't a use case we've had to address before (at least, not commonly enough for anyone to have contributed anything in this area).

The general approach would be add a listener (in the editor) to the nodes:add and nodes:remove event to keep track of how many nodes of this particular type have been added. (as @TotallyInformation has suggested whilst I type this)

But the editor doesn't provide a way to block adding a second node to the workspace based on any custom validation or rules. At best, you could then use RED.notify("Uh oh") to warn the user they have made a grave mistake.

There are a bunch of edge cases you'd need to think about. Dragging a node into the workspace isn't the only way a node can be added. There's copy/paste and import to consider. They all trigger the same set of node:add events ultimately.

4

okay, i get how i would "enforce" a singleton, im very thankful of that.
I just wonder wether having a node that isnt even initialized, because

RED.nodes.createNode(this, config);

hasnt been called yet, showing up in the editor could be considered a bug or a feature.
I guess sometimes things just do be like that.

5

It isn't a bug. The editor shows you what the flow configuration contains. If it contains two nodes of a particular type, it shows you those nodes.

If it hid any nodes that encountered an error whilst starting, then you'd have no way to edit/fix the node.

6

i would have expected it it to error out when i hit deploy, tho, perhaps i overestimated what the editor is supposed to do and what not.
thanks for the heads up, im rather new to node-red, so im sure this information will prove to be very helpful in the future!

7

But surely, generally you would not want a poorly coded node to prevent Node-RED from starting? And indeed, how would the palette manager cope in such a case? The nature of Node-RED is that you want it to be as stable as possible. So a poorly coded or misconfigured node should indeed raise an error in the log but should only cause NR to stop in very extreme cases. Then I can still remove the node using the palette manager and Node-RED continues to work.