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 repositoryand added to the Node-RED Flow Library to make themavailable to the community.
- Creating your first node
- JavaScript File
- HTML File
- Packaging
- Node properties
- Node credentials
- Node appearance
- Node edit dialog
- Storing context
- Node status
- Configuration nodes
- Help style guide
- Adding examples
- Internationalisation
Since Node-RED 1.3
General guidance
There are some general principles to follow when creating new nodes. These reflectthe 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.
