Node Creation oneditprepare


I used the first node example from the Node-RED documentation to wrote a first little node. Thanks for that easy to understand example anyway. I enhanced the example to not only use msg.payload as input, but a configurable field. This should be an easy exercise.

My field is named inField. It and a hidden -type field are created as documented. In oneditprepare I defined some additional input parameters:

    	type: 'msg',
    	types: ['str', 'msg', 'flow', 'global', 'jsonata', 'env'],
    	typeField: '#node-input-inField-type',
    <div  class="form-row">
    	<label for="node-input-inField"><i class="fa fa-cog"></i> Input</label>
    	<input type="text" id="node-input-inField" placeholder="...">
    	<input type="hidden" id="node-input-inField-type">

I also wrote an on event to fetch the change of the type.

    $('#node-input-inField').on('change', function (event, type, value) {...}

The edit mask looks well, event is triggered. :slight_smile:

However, it's not clear to me how to store and handle input field type changes and let Node-RED handle this. Maybe I didn't find it, or the docu is somewhat short on this part, or it must be that obvious, that it's not even worse to mention it.

Let's say the user selects type 'jsonata' and value '"ABCD"' (I know it's a constant that could be done by a string, but hey, it's just an example) . The event is fired. Where and how do I have to store the new type, so that it remains? NR stores the value automatically, but not the changed type.

And in addition, a 2nd question:
I guess I have to perform the data interpretation myself. So, in my .js, on input, I get the value "ABCD" in the config object, but not the type (str, msg, jsonata, ...).

Are there examples how to do this?

This should also be stored automatically for you. Perhaps you are setting this manually?

There are helper functions to do this: RED.util.evaluateNodeProperty


function myNode(config) {
    RED.nodes.createNode(this, config)
    const node = this
    node.inField = config.inField || "payload"
    node.inFieldType = config.inFieldType || "msg"

    node.on('input', function (msg) {
        let inField
        RED.util.evaluateNodeProperty(node.inField, node.inFieldType, node, msg, (err, value) => {
            if (err) {
                node.error("Unable to evaluate inField", msg)
                node.status({ fill: "red", shape: "ring", text: "Unable to evaluate inField" })
                return//halt flow!
            } else {
                inField = value
        // do stuff with inField
RED.nodes.registerType("myNode", myNode)

1 Like

Hi Steve,

thanks for your quick answer. I still believe it's a very trivial issue, but I don't get it. I wonder, if it's some syntax issue here.

This should also be stored automatically for you. Perhaps you are setting this manually?

No, the HTML code is as shown above with the node-input- field and node-input--type field. The typedInput as well only contains these three displayed fields. There is no oneditsave, or something.

node.js v18.12.1
Node-RED v3.0.2

oneditprepare: function () {
		type: "msg",
		types: ["str", "msg", "flow", "global", "jsonata", "env"],
		typeField: "#node-input-inField-type"
	$("#node-input-inField").on("change", function (event, type, value) {
		console.log(type + " - " + value);

The list of types is available, so the oneditprepare is used. I just detected, that with the above definition the field type always open with 'str', not with 'msg'. Probably because it's the first entry in the list of types. Maybe that's the problem and the type is ignored?

Changing the field type in the dialog works. If changing e.g. to 'jsonata' the JSONata editor is available. But after clicking 'Done' and re-open the type changes back to 'str'.

There are helper functions to do this: RED.util.evaluateNodeProperty

Thanks a lot. That link was new to me. I'll have a look. :slight_smile:

TypedInput Widget : Node-RED

I knew these examples. They were my source.

Have you added inField-type to the defaults property of the node? Without that, the editor won't know to store/retrieve the value of that input.

It isn't necessary to add your own change listener on it, if everything is configured properly

1 Like

Hi Nick,

wonderful! That was it!

Thanks a lot for your quick and qualified help. Really appreciate it.

Maybe it's worse to to add a note to the documentation.

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