Singleton Node concept

[gregorius]

Hi There!

Quick question concerning the singleton pattern - is there a best-practice for having singleton nodes? I.e. nodes that can only be included once in a project and/or flow?

I have no specific use-case, just a thought experiment.

But on that note, has anyone considered implementing the design patterns in Node-RED? Is that a thing? Obviously not all would be applicable to Node-RED but Node-RED could be a good way to visually teach people about those concepts...

Cheers!

[Steve-Mcl]

@gregorius

Quick question concerning the singleton pattern - is there a best-practice for having singleton nodes? I.e. nodes that can only be included once in a project and/or flow?

A config node (like the MQTT config or the serial config) are in essence singleton nodes.

Additionally, it is trivial to design a flow that makes any node singleton. Here is an example using link-call:

@gregorius

But on that note, has anyone considered implementing the design patterns in Node-RED? Is that a thing? Obviously not all would be applicable to Node-RED but Node-RED could be a good way to visually teach people about those concepts

I dont know of such a resource for Node-RED and while it would be not everyones flavour, it may prove useful for folk.

Here are a few good (IMHO) practices that I use and impart when asked (based on many years of programming in many different languages and applications):

• Stay as PURE as possible (i.e. avoid context, pass data in via the msg, get the result from the msg)
• Learn and understand the JOIN node as early as possible into your Node-RED adventure. It will help you understand one of the most fundamental parts of node-red (i.e. messages NEVER arrive from different wires at the same time)
• Dont shoot the messenger - i.e. try to ALWAYS return the original msg object - it may have extra things in that are needed downstream (like dashboard, Link-Call, TCP and HTTP nodes all need the original msg since it contains important routing info)
• When to and when not to use a subflow
• Dont loop - use the split and join nodes
• Use the copy path button on the debug to avoid typos
• Learn the shortcuts to save time (especially ctrl+shift+p then start typing)
• Use the correct mode when deploying
  • many people NEVER change from full deploy to flow or node deploy - and wonder why deploy takes a loooong time and wonder why injects are re-occurring and connections are getting dropped (hint: full deploy completely stops, destroys and re-builds ALL of the flows and nodes node-red server - not just the ones you changed)
• Using ${MY_ENV_VAR} in the text fields of a node to facilitate common flows that do different things depending on the value set in the computers environment variables (docs)
• Best practices in reading/writing to PLCs and industrial controllers (i.e. group multiple reads & writes into single transactions to avoid consistency errors & speeds up comms an order of magnitude)
• Use PARAMETERS for SQL (dont build your own SQL Query as a string - you risk SQLi)
• Not programming like its a C++ or an embedded system (i.e. use the event based nature of node/node-red to make things happen, dont poll if avoidable, avoid tight loops (see "Use the split node" above))

[gregorius]

@Steve-Mcl

Additionally, it is trivial to design a flow that makes any node singleton. Here is an example using link-call:

What I was thinking of was an enforced singleton, i.e. attempting to drag a second instance of a node onto the flow is prevented. So in your case you have several link-call nodes but only one gets called. That is singleton by convention but not enforced. True, what I'm advocating doesn't potentially make sense in Node-RED however knowing this can also be useful.

@Steve-Mcl

Here are a few good (IMHO) practices

Thank you for the that list, very interesting - I might well integrate that into an article on Node-RED (with reference though!)

@Steve-Mcl

Use the copy path button on the debug to avoid typos

Hm, didn't see that button on the debug node, I am I missing something?

@Steve-Mcl

(i.e. use the event based nature of node/node-red to make things happen, dont poll if avoidable, avoid tight loops

That is so important, remembering that makes life a lot easier and Node-RED faster! It comes down to understanding NodeJS and how everything is basically event-driven.

@Steve-Mcl

When to and when not to use a subflow

I would use more subflows if I could integrate them into my node packages, as far as I read, it's either a package with nodes or one with subflows but I can't create a mix of both. Also that I can't add parameters to subflows (at least not in the editor) is a drawback for me.

Being honest, I end up doing a lot of copy and paste instead of creating subflows - not the best solution.

[Steve-Mcl]

@gregorius

Being honest, I end up doing a lot of copy and paste instead of creating subflows - not the best solution.

That is where link-call shines. It kinda promotes PURE functions (by virtue you have to pass in all the stuff via msg and get the answer back from the msg)

@gregorius

@Steve-Mcl

Use the copy path button on the debug to avoid typos

Hm, didn't see that button on the debug node, I am I missing something?

There’s a great page in the docs (Working with messages : Node-RED) that will explain how to use the debug panel to find the right path to any data item.

Pay particular attention to the part about the buttons that appear under your mouse pointer when you over hover a debug message property in the sidebar.

[gregorius]

@Steve-Mcl

Pay particular attention to the part about the buttons that appear under your mouse pointer when you over hover a debug message property in the sidebar.

Ok, sorry I assumed that it was something directly on the debug node. I mostly use tab-completion in the editor if I write out paths. I try to avoid using the mouse when coding, so I don't like the scroll, click, uncollapse hierarchy, click, copy path, click/cmd-c, paste routine

btw I hope you're not trying to say something with payload: "birth" - if so, then congrats!

[drmibell]

@gregorius

What I was thinking of was an enforced singleton, i.e. attempting to drag a second instance of a node onto the flow is prevented.

It might be possible to use the nrlint tool to do this (untested). You could define a new node category "singleton", similar to "common" or "function". Then write an nrlint rule so that for any node type in the singleton category, creating a new instance when one already exists will generate an error. This should be easy to check for anyone (not me) who knows how to write nrlint rules, since it could be tested against an existing node category, without having to write a new custom node.