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.

8

Maybe I'm missing something or stating the obvious - why can't you define the singleton profile as a related configuration node, this way regardless of how many nodes the user adds, the profile exists only once, and its state can be reflected in a global context var?

2 Likes
9

to be honest, i dint know that was a thing. I only started using node-red yesterday, while having done a fair share of work with nodejs/webdev/typescript in general. i basicially came in with the wrong assumption that the experience can translate 1 to 1 to node red, which obviously proved to be wrong.
I was basicially just confused with the error-handling of the runtime.
dont get me wrong, stability should be the utmost priority in node red, i get that, but in my opinion its just not very intutive for exceptions in the startup of a node to not register in the editor at all. i would have at least expected the node to have a visual marker that says something like "hey, i have an uncought error and cant work", instead of basicially halting the flow that relies on the node in question, which is very annoying in my opinion. But these are just my two cents.

10

You could keep state across all your nodes with a class using static:

'use strict';
const NODE_TYPE = "<YourNodeType>";

class NodeRedNode {

    static messageReceivedCount = 0;

    constructor(RED, thisNode, config) {
        thisNode.config = config;

        thisNode.on('input', function(msg, send, done) { 

            console.log(NodeRedNode.messageReceivedCount++);
            
            send(msg);  // Send the message onwards (if applicable)
            done();     // Call done when finished

        });

        thisNode.on('close', function(done) {
            done();
        });

    }

}

module.exports = function(RED) {
    RED.nodes.registerType(NODE_TYPE, function(config) {
        RED.nodes.createNode(this, config);
        this._instance = new NodeRedNode(RED, this, config);
    });
};

But I may be mis-understanding what you want...