Node output contract

We're developing some custom nodes to easily work with a certain Rest API.

I'd like the users of the nodes to easily see what data they are getting. How can I best achieve this?

I've found the "Message properties" help: Node help style guide : Node-RED

But this only adds a human readable help text to the node. Is there any other way, or development ongoing, that would actually assist the user when using the nodes? I.e. have an autocomplete functionality when extracting a field in the payload.

Welcome to the forums @Sanderd17

The messages flowing through Node RED, are basically Javascript Objects.
So providing you document the expected object in your User Help Material, they will know they can access any property you have documented.

example.

/* result being an example property */
const APIResult = msg.payload.result

/* User does something with APIResult */

It's important you ensure the bulk of your output is within the msg.payload property, its not a technical requirement, but the payload is the common expected property within the Node RED platform, and used by core nodes.

You can provide inline Help as part of your Module, that will appear in the Side Bar, and often a good approach is to document examples, that they can expect.

Lastly, users can attach any output to the debug node - allowing them to review the output, and understand what they are receiving, allowing them to then work with the object during runtime.

EDIT
Forgetting to mention, the debug node, allows users to copy the path to an object/property/some other path to an object, so some slight assistance is available, but its important to not depend on this approach, and ensure documentation is available, Node RED allows for example flows to be included with a module, that users can import - so that is also helpful to make use of.

We have started some work on how nodes can provide types definitions for their properties and messages. It early stages, and focused on the base schema before thinking about what features it would unlock.

3 Likes

Don't forget that the node's panel in the Editor is an HTML form. Have a look at what you can do with HTML inputs to see if any of those features would help (such as specifying an input type or mask).

You also have access to both HTML/CSS/JavaScript and JQuery and so it is pretty straight-forward to add interactive input helpers and enhanced tooltips. You can also have dynamic info panels in the config panel that react to inputs.

If you have multiple nodes that might need to share some validation or other code, you can use an Editor plugin to provide that.

Example of all of this in the various UIBUILDER nodes if you want to check out some code.

This was indeed the kind of feature I was looking for. Mildly sad to see it doesn't exist yet, but great to notice it's on the roadmap.

When it comes to the decision between TypeScript and JSON schemas, I'd like to add my 2c. For our usecase (adding nodes to work with a REST API), it doesn't matter a lot. But it shouldn't be underestimated how much more advance TypeScript is than JSON schemas.

TS is made to have very advance type algebra, where you can base return types on the input type of the function (i.e. adding or removing one property on a type, without knowing what the rest of the type looks like). This is something that different nodes in Node RED can definitely use IMO. And TS was also designed to be fully compatible with JS (allowing to have an any type to catch all unknown cases). So it should be possible to use TS without requiring all node authors to start using it (their nodes will simply return an any type).

Also with the plans of Node.js supporting TS (at least supporting type stripping) in the near future, adding TS support to custom nodes will become possible without compilation, and would only require type extraction for use when editing (or whenever type checking is supposed to happen).

I do agree that adding support for TS will be harder than support for JSON schemas. But TS also has a lot of tooling, like great AST parsers, tools to extract the type definitions from .ts files, ...

But as said, I'd be glad if this makes it into the product, whether it's based on TS or JSON schemas.