-
Notifications
You must be signed in to change notification settings - Fork 151
Flow Dev Guideline
This page is for discussing about how to make Flow Dev Guideline.
You can check the original contents of Designing messages and Design pattern at HERE.
- Making application with Node-RED
- Components of Node-RED
- Style
- Align nodes
- Naming rule
- Using proper nodes
- Universal nodes that are not recommended for heavy use
- Changing icon
- Designing a flow
- Development process
- Designing domain model
- Designing flow structure
- Designing messages
- Parameter that stores data shared between nodes
- Parameters that control the functionality of a unique node
- In a node to which multiple messages with different types are input, add tag information for identification to each message.
- Store a large amount of data in persistent storage outside Node-RED and reference the data.
- Processing depending on the order of arrival of messages
- Implementing flow
- Collaboration between flows
- Implementing message
- Managing environmental variables
- Managing status
- Flows that can have adverse effects
- Improving readability and reusability
- Comment
- Error Handling
- Refactoring
- Development project
- System and development environment
- Managing flow
- Responding to strict non-functional requirements
- Precautions due to single thread
- Sequential duarantee
- Design pattern
- Pattern regarding the structure between flows
- Facade pattern
- Pattern related to managing status
As the size of the application increases, the processing contents become complicated. It makes it hard to understand by other developers. Therefore, it is important to make the process easy to understand with better node alignment.
Name to nodes and tbas also affect readability and reusability of flows. This chapter present some examples useful for it.
If nodes are used for different purpose, there is a possibility of erroneously recognizing the flow. This chapter introduce how to representative nodes such as Change, Switch, Template, Link, HTTP for using these as the original role.
Function node and Exec node may be easy to use for skilled developers because they can write down JavaScript or command directly. However, heavy using of these make contents of the flow hard to understand unless some one check the each node. This chapter is a caution to prevent about it.
When the same kind nodes are in the flow, it is difficult to distinguish nodes. But, it can be solved by designating different icons for each node. This chapter introduce the procedure for changing the icon and some Use Cases.
When develop a flow has complicated logic, it is better to design and develop strategically.
As the volume of the tab increases, the division of processing becomes ambiguous. If the flow is intended to be reused, it is necessary to decide processing contents and scale of one tab before implementation. For that reason, it is better to organize what kind of things, people, work, rules are in the target domain of the application, and what relation it has.
After designing the domain model, consider the structure of the flow that reflects it.
Messages can cause dependencies between multiple nodes. For other developers to reuse flows, it is important to design messages so that dependencies get to be relaxed. Therefore, this chapter proposes a guide about designing message.
- Do not make multiple nodes use same property
- Importance of dividing data processed by node(msg.payload property) and controlling feature of node(msg.).
- How to prevent
- Recommended pattern of parameter setting
In a node to which multiple messages with different types are input, add tag information for identification to each message.
- Necessity of tag due to the fact that there is only one input port of node
- Points to note when handling large amounts of data
- The order of arrival of messages when processing multiple messages
// Accumulation of messages
var msgs = context.get('messages') || [];
msgs.push(msg);
if(msgs.length === ...) {
... // Process messages
}
context.set('messages', msgs);
Well designed sample flows help development of flow, especially for Node-RED beginers. This chapter introduces general design patterns.