So after about one year of the last developed node, a new client stumbled upon me to create a node for a specific domain register website. They do have the API and this will be very easy to code...
I want to deliver as a fully professional-built node, but I will update the API parts weekly.
So the main question is: What should a group of nodes have? I need a checklist I could follow, and decided to ask here on the forum, while looking at some other 'stock' nodes...
Well that is a VERY open-ended question and obviously depends very heavily on what you are delivering and how. The official docs on creating your own nodes contains all of the basics as well. But here are a couple of thoughts anyway to maybe get things going:
- The code should be in GitHub if you are making it available.
- There should be a comprehensive
package.jsonfile - try the uibuilder package as an example since I think I have everything important in there. - There should be a good README that describes what the nodes do succinctly, how to install them and where further documentation on usage can be found (that can be in the README if the nodes are simple).
- If your nodes pass messages through, they should not override the content of the incoming msg unless there is a really good reason to do so and it is clearly documented.
- Nodes should generally use msg.payload for the most important data content.
- Nodes should allow the use of msg.topic. You might allow a default topic to be set in the node's Editor panel if appropriate.
- All nodes should allow the setting of a
namefield in the Editor panel.
What else?
2 Likes
Some extra points besides Julian's nice overview:
- Make your example flows available via the "Import" menu in the flow editor.
- The info panel should contain the most important information about your node. And add on your Info panel a link to your "Import" menu example flows, as @Steve-Mcl has described in another discussion.
2 Likes
You mean this?
2 Likes
