-
Notifications
You must be signed in to change notification settings - Fork 153
Node Dev Guideline
This page is for discussing about how to make Node Dev Guideline.
This page covers what will be added to the Node-RED official homepage document Creating Nodes.
This page is for discussion on Slack and this page will be added and changed based on it.
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.
Nodes are basically identified from icons, colors and names. Icons and names can be changed later by the user, but since they are basically used as they are, determining these items is a very important consideration item for node identification.
This part introduces the criteria for creating icons.
- Use existing icons provided by Node-RED.
- Create an icon for each product / function
- Create an icon for each node
Select the color listed in Background Colour or specify the unique color of the product.
| Item | Whether change by user is possible |
|---|---|
| Node name | Permitted by node |
| Icon | possible |
| Node color | impossible |
| Number of input ports | impossible |
| Number of output ports | Allowed by node |
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 for quality improvement.
There are three methods. 1.Static analysis 2.Manual test with operating Node-RED 3.Automated test with test code Below, these three procedures will be explained.
By using the static analysis tool, it is possible to detect coding standard violation which can not be confirmed by error of source code or test by code execution. In addition, by using a code editor that can cooperate with the static analysis tool, it is also possible to prevent the above creation from coding time.
Check the operation by installing its own node in Node - RED and running it on Node - RED.
Create test code and test automatically. In consideration of test efficiency and regression test, it is desirable to be able to perform automatic test with test code as much as possible. In this part, preparation of test environment, creation of test code, execution, and notes will be explained.
- Testing package.json When Node - RED reads its own node, it reads by referring to the package.json of the node. Therefore, if there is an error in the description of package.json, it can not be read normally. It is recommended that you actually use the npm command to install your own node as an npm package and test whether it can be read by Node - RED.
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