Creating Nodes
The main way Node-RED can be extended is to add new nodes into its palette.
Nodes can be published as npm modules to the public npm repository
and added to the Node-RED Flow Library to make them
available to the community.
Since Node-RED 1.3
General guidance
There are some general principles to follow when creating new nodes. These reflect
the approach taken by the core nodes and help provided a consistent user-experience.
Nodes should:
-
be well-defined in their purpose.
A node that exposes every possible option of an API is potentially less useful
that a group of nodes that each serve a single purpose.
-
be simple to use, regardless of the underlying functionality.
Hide complexity and avoid the use of jargon or domain-specific knowledge.
-
be forgiving in what types of message properties it accepts.
Message properties can be strings, numbers, booleans, Buffers, objects, arrays
or nulls. A node should do The Right Thing when faced with any of these.
-
be consistent in what they send.
Nodes should document what properties they add to messages, and they should
be consistent and predictable in their behaviour.
-
sit at the beginning, middle or end of a flow - not all at once.
-
catch errors.
If a node throws an uncaught error, Node-RED will stop the entire flow as the
state of the system is no longer known.
Wherever possible, nodes must catch errors or register error handlers for any
asynchronous calls they make.
