Contrib-config Causing issue with 1.0

Other people have complained about this since 1.0 beta. Here is the console error which doesn't make much sense.

red.min.js:16 Uncaught TypeError: Cannot read property 'icon' of undefined
    at t.<computed>.<computed>._updateOptionSelectLabel (red.min.js:16)
    at t.<computed>.<computed>._updateOptionSelectLabel (vendor.js:formatted:4691)
    at t.<computed>.<computed>.value (red.min.js:16)
    at t.<computed>.<computed>.value (vendor.js:formatted:4691)
    at HTMLInputElement.<anonymous> (vendor.js:formatted:4734)
    at Function.each (vendor.js:formatted:146)
    at e.fn.init.each (vendor.js:formatted:74)
    at e.fn.init.t.fn.<computed> [as typedInput] (vendor.js:formatted:4731)
    at Object.addItem (<anonymous>:48:34)
    at red.min.js:16

I tracked it down to this code block but it's this single line that causes the issue

 propertyName.typedInput('value', property.p);

With the type as flow or global the value can not be set. Any ideas on what to try? I change this to a str instead and I don't get any more errors but the code obviously doesn't work.

                addItem: function(container,i,property) {
                    if (!property.hasOwnProperty('p')) {
                        property = {p:"",pt:"flow",to:"",tot:"str"};

                    var row1 = $('<div/>').appendTo(container);
                    var row2 = $('<div/>',{style:"margin-top:8px;"}).appendTo(container);

                    $('<label/>',{for:"node-input-config-property-name",style:"width:110px; margin-right:10px;"}).text("Property").appendTo(row1);

                    var propertyName = $('<input/>',{style:"width:250px",class:"node-input-config-property-name",type:"text"})

                    $('<label/>',{for:"node-input-config-property-value",style:"width:110px; margin-right:10px;"}).text("Value").appendTo(row2);
                    var propertyValue = $('<input/>',{style:"width:250px",class:"node-input-config-property-value",type:"text"})

                    propertyName.typedInput('value', property.p);
                    var newWidth = $("#node-input-config-container").width();
                resizeItem: resizeConfig,
                removable: true,
                sortable: false

The module is node-red-contrib-config

The contrib node needs fixing, have you opened an issue on the nodes github page?

There is one,, but that hasn't been touched in over two years so I'm not holding my breath. I don't mind fixing it but I have no idea why that's not working, it seems like a nodered issue to me.

Ahhh see Where Did I Go?


Thanks, I'm not sure this is related to any css changes, it seems like it's a JS issue when trying to set the value on the typedinput.

If this issue is specific to contrib node contrib-config then it would be good to change the title of the post to make easier for people to understand it and not open similar posts in the future.

I'm stumped. It only breaks with the type for that input is global/flow. I can change it to anything else, msg, str, etc and I don't get that error and things work.

JFI - I tried this node out to see if I could help find the error but I have a different issue with it

I set flow.ctest to foo in one node and made that the active one
I then set flow.ctest to bar in another copy and made that not active

pressing the buttons alternatively switched flow.ctest between foo and bar

Redeploying flow reset flow.ctest to foo
Stop and starting Node-RED itself reset flow.ctest to foo

So it worked fine for me......but ....

the value (foor or bar) is blank when I re-edit either of them

Do you get errors in your javascript console?

I get errors but I've no idea where they are coming from (I'm no expert on the console - I only use it if someone tell me to look at it)

So you're seeing the same error as me, it's related.

Well - just spent 2 hours playing with this and for life of me, I don't know why it doesn't behave properly on 1.0.0 :frowning:
However, I have found a workaround - although it still gives the error in the console - it displays the previous saved values so if you ignore the console error - you can carry on using it :slight_smile:

The bodge fix is to swap the lines around in config.html




please give it a a try and see if it works for you

I have the exact same error with a node of mine.
Here's an excerpt of the code I used:

field = $('<input/>',style)
field.typedInput("type", rule.value1Type || 'bool');
field.typedInput("value", rule.value1);

(this typedInput is used with a multi-rules widget like the one in the switch/change nodes)
It turns out that rule.value1 equals true by default (for a new rule) and that typedInput in NR 1.0 does not like that !

If I replace the last line with

field.typedInput("value", rule.value1.toString());

then it doesn't throw the error but on the other side, my field is now a string a not a boolean !
@knolleary is there any change in NR 1.0 in the behavior of typedInput ? Maybe I overlooked the info somewhere ? Thanks.

There have been some internal changes to typedInput, but nothing that was intended to break this sort of usage.
Will investigate.

Thanks. To be fair, it seems that it doesn't really matter if my field is a string as it seems (and I should investigate further) that it was the way it worked in NR before v1.0 (inspecting flows.json I see these fields are string with "boolean" values)... the only thing that clearly changed is the fact that NR doesn't like a bool when using value .

Have pushed a fix. We'll have 1.0.1 out today/tomorrow with it in.

I did also check the behaviour in 0.20 and whilst it doesn't throw the error, nor does it do quite what you expect.

If the type has been set to "bool" and you pass it the value true or false (ie Boolean types, not Strings), then it doesn't set the value of the typedInput to the corresponding value. This is because it is expecting the values to be "true" or "false" and it does a strict comparison. I've relaxed that a bit so if the options available in the node are strings and you pass in a non-String, we'll toString it before comparing.

1 Like

Will this fix the issue we were seeing with the contrib-config node too?

I haven't checked it explicitly, but its the same error in the log, so I would expect so.

1 Like

Great ! Thanks !