I really love the low code environment that node-red provides, but I am struggling with one aspect when it comes to maintainability and avoiding bugs. In a more traditional coding environment, it's obvious when invoking a function what arguments it requires.
In Node-red, however, I find that these requirements are quite hidden: it's very easy to pass a message to a node that does not contain the correct data, or for an upstream node to inject extra data that a downsteam node doesn't know how to handle. All this can happen quite invisibly. I find this issue to be even more difficult when I use lots of subflows. Without cracking open the subflow, it's difficult to determine what 'arguments' the subflow is looking for.
Sometimes, a node can consume extra data that it doesn't need without complaining, sometimes not. All in all this is leading me to very bug-prone flows. I've taken to adding a lot of 'extra' logic to my subflows to strip out extra data in messages that it can't properly handle, but this seems entirely unmaintainable, and it means that external dependencies are leaking into my subflow 'functions'.
I realize that node-red is it's own thing, and doesn't (nor should it) perfectly replicate the model of function-calling, but I would love to hear what suggestions and methods you use to try to alleviate some of these friction points in your own flows? I'm willing to evolve my methodology, but I'm having trouble understanding how node-red 'wants' these sorts of things handled.
But lets not forget, nodes (core or community provided) do have documentation (most of the time), that can be accessed within Node RED that is designed to hint at the shape of the expected message for the End User.
Subflows is no exception, they can also hold meta information.
In general, nodes should simply ignore properties they aren't interested in so if you find some that aren't doing that, feel free to nudge the author of the node.
So it is actually pretty rare, normally, to have to worry about anything other than the msg.payload and maybe (occasionally) the msg.topic.
For documenting flows. You have the description that all nodes and all flow tabs now have. Though that is currently not especially well exposed in the UI. I mostly use comment nodes and groups to clearly document my flows as in this example:
It should not consume extra properties, it should ignore them and pass them on.
You should always attempt to preserve data that you are not interested in as adding information into messages can be a very powerful way of passing data down to later nodes. It is very annoying when one finds that a node destroys properties that it should just ignore. Can you give some examples of where additional properties in a message have caused problems?
I can relate with these sentiments... it's far too easy (and hidden?) to pass a string in msg.payload that the node is expecting in msg.url (for example -- which I just did!).
While the debug sidebar is valuable for showing what is expected on the input msg object, there are times when it would be nice to have the receiving node kick out a warning when it does not get what it expects -- but continue to run as usual. Seems like if each node had an option to specify some JSON Schema, that could be used as a pre-invoke validation step.
I think the only node that currently validates against a JSON schema is the json parser node. I see there are a dozen other contrib nodes that try to inject schemas into the msg or stop msgs passing through if they are not valid -- but nobody wants to insert a validation node in front of all the existing nodes in their flows.
Seems like this could be an optional property with it's own editor panel, like the node styling editor. Even better, use the JSON schema to generate the Markdown text for msg input section of the help sidebar?
I had the same feeling about not knowing what properties a msg object requires so I put together the validation node which uses a JSON schema to validate msg objects. The discussion behind the node.
I use that node in a couple of places but it's still not "easy to use, out of the box" stuff.
