Node boolean property converted to string

[BartButenaers]

Hi folks,

I was trying to solve this dashboard issue, but I am a bit confused.

1. The ui-slider node has a boolean property:

        RED.nodes.registerType('ui-slider', {
            defaults: {
                ...
                thumbLabel: { value: true },
   

2. When we double-click the node, the oneditprepare is triggered where that boolean true is loaded as a string "true" in the html element:

   

3. When you click the "Done" button of the config screen, the oneditsave is triggered where the string "true" from the html element is converted back to a boolean true and stored in this node:

   

   So I expect the node state is again the same as in the beginning.

4. But when you double-click the node again, the value in the oneditpreare seems to have become a string "true" (although we have stored in the previous step a boolean true):

   

The switching between the boolean and string values results in the node becoming dirty, and the "Deploy" button becoming active.

Does anybody know why the stored boolean value becomes a string? I assume it is being stored as a string value, because the loading works fine the first time.

Thanks!!
Bart

[TotallyInformation]

Not really followed that closely but my suspicion is that the boolean is being added as an HTML element attribute? If so, attributes are always strings. So you need to convert it back.

[BartButenaers]

Yes Julian that is correct:

• when you put a value in a hrml element of your config screen, then you need to convert it from a boolean to a string (in oneditprepare).
• when you get the value afterwards from the htmk element, then you need to convert it from a string to a boolean again (in oneditsave).

Both have been implemented correctly by Joe.

But the problem is: he saves a boolean into his node (in oneditsave) and afterwards (in oneditprepare) it is a string again.

Or is that standard behaviour? Too long ago. Don't remember anymore what is best way to deal with this...

[hotNipi]

I think, (not tried) the converting should be removed from editor and the actual usage of that property in vue should be made by using computed value. But may introduce breaking change...

[BartButenaers]

Morning @hotNipi,
It is from the config screen, not the vue file. So the computed fields are not applicable to this issue. Too long ago that I wrote this kind of code, so a bit confused what is the best practice. My knowledge seems to be fading away...

[hotNipi]

I'll try once more...
The usage of that property is in vue. The type of the property should be even string ('always') or boolean.
The converting in config is unnecessary if the property usage will be via computed value.
Let the it be string ("always", "true", "false") and use computed value in vue where you then convert "true" or "false" to actual boolean.

[BartButenaers]

Ok, thanks. Seems my brain is not fully awake yet. That makes sense yet.

But would like to understand what is wrong with Joe's code, because I don't see it. The default value is a boolean, and that arrives as a boolean in the oneditprepare. But afterwards it can never be a boolean again, only a string boolean? Was that normal behaviour of node properties? Joe is using boolean node properties all over the place, so I don't understand why this one causes an issue for some user.

[hotNipi]

I think Joe was trying also to avoid breaking changes. Previous iteration had checkbox to even show or hide. The input element is now select and for that the handling is different thus the property needed to be converted. But as we know now, the converting in config has that nasty side-effect.

[GogoVega]

String because select input. Outside of checkboxes (boolean), the value saved by the node (without oneditsave) is a string.

oneditsave has its own change mechanism, just like the internal editor save.

When oneditsave is called, it will transform the string into boolean - a change is detected.

When the internal editor save is called, the value previously changed to boolean will be changed back to string - here too the node detects a change.

That's why the oneditsave fails because the value is overwritten by the internal editor mechanism. So the value exported is always a string.

[BartButenaers]

Ok thank you all for illuminating me!
Will try to fix that dashboard issue as soon as I find time.
Have a nice day!

[GogoVega]

You'll have to check with Joe if the code in oneditsave is necessary. I assume it was a migration initially.

[BartButenaers]

@GogoVega (or other users of course...),

I have been doing a series of other PR's, but this one has lost my attention meanwhile. So I created a simple node to refresh my knowledge:

<script type="text/javascript">
    RED.nodes.registerType('test-data-conversions',{
        category: 'function',
        color: '#a6bbcf',
        defaults: {
            someString: {value: "initial"},
            someBool: {value: true},
            someInt: {value: 5}
        },
        inputs: 1,
        outputs: 1,
        icon: "file.svg",
        label: function() {
            return this.name||"lower-case";
        },
        oneditprepare: function() {
            debugger
        },
        oneditsave: function() {
            debugger
        }
    });
</script>

<script type="text/html" data-template-name="test-data-conversions">
    <div class="form-row">
        <input type="text" id="node-input-someString">
    </div>
    <div class="form-row">
        <input type="number" id="node-input-someInt">
    </div>
    <div class="form-row">
        <input type="checkbox" id="node-input-someBool">
    </div>
</script>

<script type="text/html" data-help-name="test-data-conversions">
    <p>A simple node to test data conversions</p>
</script>

The first time I arrive in the oneditprepare I get these values:

So the properties in this are simply the default values (with the correct types), assigned by the flow editor to my new node. But I had expected value "false" instead of "on"....

The second time I arrive in the oneditprepare I get these values:

So the boolean is still a boolean, and the number is still a number. Which means not everything is converted by the flow editor to string values?

Somehow I am completely confused. Too long ago that I used this stuff
I would really appreciate if you could illuminate my old brain...

[Steve-Mcl]

@BartButenaers

But I had expected value "false" instead of "on".

Use $(....).is(':checked') for checkbox

@BartButenaers

The second time I arrive in the oneditprepare I get these values

Try changing values (check on -> off, 5 -> 6, "initial" -> "changed"), press done then re-open & see values in oneditprepare once more.

[BartButenaers]

OMG @Steve-Mcl, done that thousands of times and completely forgotten...
Thanks for refreshing my brain!!

For those ever having the same question:

The first time I double click the node, I arrive in the oneditprepare with these values:

So the properties in this are simply the default values (with the correct types), assigned by the flow editor to my new node.

I change all 3 html input fields, and press the "Done" button.
In the oneditsave the this properties still contains the original values, but the html input elements contain the new updated values:

After this function, the flow editor automatically converts everything (except booleans) to string values.

The second time I double click the node, I arrive in the oneditprepare with these values:

All the property values have become strings, except for booleans.