# What is the "NodeRed" way to approach this? \[Argument Validation\]

**URL:** <https://discourse.nodered.org/t/what-is-the-nodered-way-to-approach-this-argument-validation/84845>\
**Category:** General\
**Created:** [23 January 2024 19:29 UTC](https://discourse.nodered.org/t/what-is-the-nodered-way-to-approach-this-argument-validation/84845 "2024-01-23T19:29:26Z")\
**Posts on this page:** 9\
**Page:** 1

<div class="post-metadata">

**Author:** ![Hyperlooper](https://sea2.discourse-cdn.com/flex026/user_avatar/discourse.nodered.org/hyperlooper/32/85843_2.png) [@Hyperlooper](https://discourse.nodered.org/u/Hyperlooper)\
**Post date:** [23 January 2024 19:29 UTC](https://discourse.nodered.org/t/what-is-the-nodered-way-to-approach-this-argument-validation/84845/1 "2024-01-23T19:29:26Z")

</div>

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.

---

<div class="post-metadata">

**Author:** ![marcus-j-davies](https://sea2.discourse-cdn.com/flex026/user_avatar/discourse.nodered.org/marcus-j-davies/32/103435_2.png) [@marcus-j-davies](https://discourse.nodered.org/u/marcus-j-davies)\
**Post date:** [23 January 2024 19:47 UTC](https://discourse.nodered.org/t/what-is-the-nodered-way-to-approach-this-argument-validation/84845/2 "2024-01-23T19:47:29Z")

</div>

I think your topic is a very valid point.

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.

Here is one I made earlier:

 ![Screenshot 2024-01-23 at 19.46.40](https://us1.discourse-cdn.com/flex026/uploads/nodered/original/3X/b/2/b27541d89a4fdee5607d02348f45903d797189fa.png)

---

<div class="post-metadata">

**Author:** ![Steve-Mcl](https://sea2.discourse-cdn.com/flex026/user_avatar/discourse.nodered.org/steve-mcl/32/4826_2.png) [@Steve-Mcl](https://discourse.nodered.org/u/Steve-Mcl)\
**Post date:** [23 January 2024 20:04 UTC](https://discourse.nodered.org/t/what-is-the-nodered-way-to-approach-this-argument-validation/84845/3 "2024-01-23T20:04:58Z")

</div>

> [@marcus-j-davies](#):
>
> Subflows is no exception, they can also hold meta information.

You can even format the help just like the core nodes : [Node help style guide : Node-RED](https://nodered.org/docs/creating-nodes/help-style-guide) using markdown style guide

---

<div class="post-metadata">

**Author:** ![TotallyInformation](https://sea2.discourse-cdn.com/flex026/user_avatar/discourse.nodered.org/totallyinformation/32/31_2.png) [@TotallyInformation](https://discourse.nodered.org/u/TotallyInformation)\
**Post date:** [23 January 2024 20:07 UTC](https://discourse.nodered.org/t/what-is-the-nodered-way-to-approach-this-argument-validation/84845/4 "2024-01-23T20:07:23Z")

</div>

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:

 ![image](https://us1.discourse-cdn.com/flex026/uploads/nodered/original/3X/1/7/1707c272000f20376a4a9d49c19647d816bea99c.png)

---

<div class="post-metadata">

**Author:** ![Colin](https://sea2.discourse-cdn.com/flex026/user_avatar/discourse.nodered.org/colin/32/17040_2.png) [@Colin](https://discourse.nodered.org/u/Colin)\
**Post date:** [23 January 2024 20:27 UTC](https://discourse.nodered.org/t/what-is-the-nodered-way-to-approach-this-argument-validation/84845/5 "2024-01-23T20:27:19Z")

</div>

> [@Hyperlooper](#):
>
> Sometimes, a node can consume extra data that it doesn't need without complaining,

It should not consume extra properties, it should ignore them and pass them on.

> [@Hyperlooper](#):
>
> 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

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?

---

<div class="post-metadata">

**Author:** ![shrickus](https://sea2.discourse-cdn.com/flex026/user_avatar/discourse.nodered.org/shrickus/32/517_2.png) [@shrickus](https://discourse.nodered.org/u/shrickus)\
**Post date:** [25 January 2024 20:49 UTC](https://discourse.nodered.org/t/what-is-the-nodered-way-to-approach-this-argument-validation/84845/6 "2024-01-25T20:49:35Z")

</div>

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?

---

<div class="post-metadata">

**Author:** ![Hyperlooper](https://sea2.discourse-cdn.com/flex026/user_avatar/discourse.nodered.org/hyperlooper/32/85843_2.png) [@Hyperlooper](https://discourse.nodered.org/u/Hyperlooper)\
**Post date:** [26 January 2024 23:12 UTC](https://discourse.nodered.org/t/what-is-the-nodered-way-to-approach-this-argument-validation/84845/7 "2024-01-26T23:12:52Z")

</div>

Thank you everyone for the suggestions. I really appreciate it.

---

<div class="post-metadata">

**Author:** ![gregorius](https://sea2.discourse-cdn.com/flex026/user_avatar/discourse.nodered.org/gregorius/32/73816_2.png) [@gregorius](https://discourse.nodered.org/u/gregorius)\
**Post date:** [27 January 2024 14:18 UTC](https://discourse.nodered.org/t/what-is-the-nodered-way-to-approach-this-argument-validation/84845/8 "2024-01-27T14:18:05Z")

</div>

I had the same feeling about not knowing what properties a `msg` object requires so I put together the [validation node](https://flows.nodered.org/node/@gregoriusrippenstein/node-red-contrib-validation-and-documentation) which uses a JSON schema to validate `msg` objects. The [discussion](https://discourse.nodered.org/t/requiring-a-msg-structure-enforcing-the-presence-of-fields-and-attributes/81432) behind the node.

I use that node in a [couple](https://cdn.flowhub.org/?t=0&fhid=390ee0021ded4910#flow/390ee0021ded4910) of places but it's still not "easy to use, out of the box" stuff.

---

<div class="post-metadata">

**Author:** ![system](https://us1.discourse-cdn.com/flex026/uploads/nodered/original/1X/d073cd938eafa2e558d7c2cd59003b3ef4963033.png) [@system](https://discourse.nodered.org/u/system)\
**Post date:** [26 April 2024 14:18 UTC](https://discourse.nodered.org/t/what-is-the-nodered-way-to-approach-this-argument-validation/84845/9 "2024-04-26T14:18:48Z")

</div>

This topic was automatically closed 90 days after the last reply. New replies are no longer allowed.