I'm a Node-RED (v4.0.0) novice trying to develop a custom node that has elements of the switch and function nodes. In trying to understand the HTML of the switch node to modify the editor panel, I've come across a couple of references that I can't find in the API or Creating Nodes documentation. In particular, RED.utils.validateTypedProperty and RED.utils.parseContextKey (I've found RED.utils.parseContextStore which appears to do the same thing).
Google is showing me nothing germane. Am I missing something, or are these considered "internal" and not documented?
Your post states that you are a 'novice' - what is the reason you 'immediately' want to develop a node - what are you missing that you cannot get away with, with the available nodes ?
I am looking at using Node-RED to replace a workflow engine, which is basically a state machine processor. While a flow looks like a state diagram, it isn't, but Node-RED's flow editor is a great way for drawing one. Using the function node I've prototyped the ability to draw a state diagram and cause state transitions (and get results, current state, etc.) via http requests. The prototype, however, requires modifying the function node's code to customize the output behavior (which output messages are sent on). I don't want the applications engineers who create these state diagrams to have to modify code, so I'm looking to have an editor UI that resembles the switch node's. This drives the shift from code in a function node to a custom node.
If you have a suggestion for an alternative platform, or even "you're torturing Node-RED into something it isn't", I'd appreciate hearing it.
There are often contributed nodes that can be used when Node-RED doesn't quite do what you want.
Certainly Node-RED is not a state machine - it is a general-purpose compute environment. However, there are a number of state machine nodes in the catalogue and you should check those out before trying to create a new node.
Thanks very much for the pointer! Are these considered internal methods and therefore not to be used outside of the node-red project as they're not documented?
Thanks for the pointer to the xstate-based node. I've looked at xstate before, and if there was a companion to the library that allowed a non-software engineer to graphically create and edit an xstate state machine I'd probably be using it. This node does half the job by being able to output a visualization and I'd certainly use it in a flow that needed a state machine that didn't need graphical editing.
However what I'm trying to do is leverage the Node-RED graphical flow editor into a graphical state machine editor. I know that the editor edits low/no code programs, not state machines, and go to great pains to explain this to folks that I discuss this idea with. However my prototype "state" node (created with the function node) makes a flow behave like a state machine (albeit one without lots of the features of a package like xstate) that can be graphically edited and defined without writing code.
The purpose of building a custom node is to give the code I used in the function node-based prototype the ability of a switch node to direct output messages via a similar drop-down/fields editor UI. That would be the final piece in eliminating the user's need to modify code. There are numerous reasons to do the switching in this state node instead of following the function node with a switch node including context size limitations (there will be over 30k instances of the state machine), flow clutter, etc. which could be discussed in another thread.
I think they are partly documented over here, at least there is some description of property validation over there.
Definitely do that, Node-RED (the frontend) is very good tool for doing such things. I created my mindmap using Node-RED, so it's definitely possible to do many things.
Heck, I even create my custom nodes in Node-RED --> instrospection nodes are maintained using this Node-RED flow. (Btw the reason for this is that I dislike the mental context switching going back and forth between my text editor and Node-RED when creating custom nodes.)
Many don't see the potential but don't give up! Node-RED has a small user based compared to other programming languages and of that user base, many just do very specific tasks (i.e. home automation, message handling from MQTT, connecting to IoT sensors ...). There is little abstracting away from those "standard" tasks or even seeing Node-RED as a graphic tool for connecting rectangles with lines (which is how I see Node-RED - to an extent).
