-
Notifications
You must be signed in to change notification settings - Fork 154
Node Dev Guideline
This page is for discussing about how to make Node Dev Guideline.
You can check the original contents of Creating node definitions for Node-RED (node generator) at HERE.
- Introduction
- Purpose of node development and correspondence of this guideline
- Designing
- Policy for designing original nodes
- Coding
- Official documentation of Node-RED
- Procedure of development
- Describing code
- Style
- Official documentation of Node-RED
- Naming rule
- Design
- Improving quality
- Test
- How to run the test
- Static analysis
- Manual test with operatig Node-RED
- Automated test with test code
- Original test items of node development
- Security and anonymity
- How to write credential information
- How to code obfuscation
- Appendix
- Tips and Notes
- Creating node definitions for Node-RED (node generator)
There is possiblity that standard nodes of Node-RED can not deal with every use case. Node-RED allows users to develop their own original nodes. This guideline explains guideline and precautions for developing nodes.
This chapter explain the policy of designing nodes for developers who make original node.
Tips about creating multiple nodes having similar functions to make flow developers can use nodes easily.
Categories, icons, and colors are important for improving readability when creating nodes.
Define the setting interface of the node. It is desirable not to make the node setting too complicated. The default setting should be the setting that is commonly used.
Designing input / output, interface, function, error handling
Designing performance, resource, security, reliability
Firstly, there are documents about how to create a new node in the Node-RED official site. Therefore, the page should be given preference.
- Designing interface
- Writing code
- Test
- Multilingualization
- Packaging
Creating a simple node or template of node could be easy for using node-generator.
The looks of nodes such as node's name, color, and icon affect the readability of the flow. This chapter give some tips to developers when they create multiple nodes.
The appearance of the node is explained in Node appearance. But, I think that it is neccessary to add the contents about rule of naming node because it is not on the official website.
When categories name and node name is similar to ones made by other developers, it is difficult for other users to distinguish them. If the category name or node name of your node is exactly the same as that of other developers, one of them will not be displayed on the palette. Therefore, these names need to be sufficiently unique.
Also, too long names reduce visibility.
This section describes guidelines for naming conventions for these problems.
There are two policies. Firstly, make it a name that can be determined with category name / node name (but do not name it according to icon or color). And make the name as short as possible.
· Only verbs · Only nouns · Verbs and nouns ＋The first letter of a word is lowercase. ＋Put a space between the word and the word.
A node must belong to one of the categories. In this part, we introduce criteria for deciding which category.
It must be uniquely identifiable together with category name and node name. And it is recommended that the node name be short so that the whole can be seen at a glance. And this part introduce bad cases aslo.
It is important to ensure the quality of it, because node could be used in every flow, and the quality of the node influences the quality of the flow. Therefore, this chapter explain about tests as quality improvement.
If the developer includes the credential information in the flow data as the property value of the node, the credential information is shared with other people when sharing the flow. And it could cause an unintended operation. Also, when place the developed node in the repository, the contents of the source code could ve read by others. This chapter describes about handling of credential information and a method of code obfuscation to prevent these bad events.
- Make state of the node can be grasped from the workspace
- Do not implement a server feature(Web server, etc.)
- If you need establishing a session with another server, do not discard the message arrived before establishing it
- Do not embed personal information
- Group the related function group of the original node into one node
- Do not assume the execution order of nodes
- Do not perform sequential processing for a long time in the node