Cannot specify node input source or output destination

[hidetak]

Server-side nodes can specify the input source and output destination on the node's configuration screen.

When creating complex flows, it would be more convenient to be able to set the input source and output destination.

I think it would be better to allow client-side nodes to specify input source and output destination as well, but I would appreciate any suggestions you may have.

[egekorkan]

I have always used msg.payload so I do not have the use case but it wouldn't hurt to be flexible? @hidetak do you already have a use case?

[hidetak]

@egekorkan

As you know, Node-RED nodes generally use msg.payload.
For example, suppose we have the following flow

A -> B -> C

If the data output by node A to msg.payload is to be used by node C, the data output by A must be temporarily stored in another member(ex. msg.tmp) and then put back into msg.payload before calling C.

For example, if you want to register the output data of an Invoke-Action node to the Web API, you would have to log in, get a token, and request the output data, which is the situation.

The ability to change input and output members would simplify the flow.
However, since the code of these node would be complex, I think it is acceptable to have a policy of not implementing this.
However, I think it would be better to have a unified policy for the server and client.

[egekorkan]

@hidetak I understand the problem. I would have just done what you have said, i.e. data output by A must be temporarily stored in another member(ex. msg.tmp) and then put back into msg.payload before calling C.

Do you think this is too annoying for our users?

At the same time, I do not understand what you mean by However, I think it would be better to have a unified policy for the server and client.

[hidetak]

@egekorkan

Thank you for your reply!

Do you think this is too annoying for our users?

I think it depends on the complexity of the flow on the client side of WoT.
For example, if it is just a matter of periodically retrieving properties and storing them in a data store, it would not be too much trouble.

At the same time, I do not understand what you mean by However, I think it would be better to have a unified policy for the server and client.

Currently, the server-side node input source/output destination is configurable, but the client-side input source/output destination is fixed to payload.
I thought it would be better to use the same concept.

[egekorkan]

Currently, the server-side node input source/output destination is configurable, but the client-side input source/output destination is fixed to payload.
I thought it would be better to use the same concept.

Ok I understand now. It would be a nice thing to do but until we have more complicated data flows, I do not see a need to prioritise it (feel free to do it though). At least, I only do the simple flow you mentioned above.

[hidetak]

@egekorkan

Thank you for your input.
I understand that we will lower the priority of this Issue.