Boolean true should equal string true (or better)

I sort of expect to be able to compare to true. So I code a switch node with "==" and look for a boolean type that I can set to true. I don't find one, so I reluctantly match with the string "true". My fairly complex flow doesn't work properly and it takes me wwaaaaayyyy too long to realise that boolean true != string true (I blame the red wine). So I Google it, and then realise "is true" and "is false" exist on the switch node. Doh! But really? How many people are going to encounter the same 'problem'? Surely most languages these days would coerce a boolean to a string and it would work.

Even better, all of this could be solved by leaving "is true" but also allow a boolean type in the comparison. I know I'm going to make the same mistake again and again. Please! Thoughts?

EDIT... And to fix up my potential mistakes in other nodes, why does searching (ctrl-F) for "true" seem to match with "on"?

Post your flow to give us some context to work with. Checking a boolean in javascript is fairly easy.

booleanValue = true

if( booleanValue === true ){
  do something
}

edit

with a switch node:

edit 2 it's early, you figured it out.

I don't think that is correct, certainly not javascript or C or Java. Can you give an example?

Maybe coerce is a strong word. In C# you'd have to do Boolean.TryParse("true"), but it would work. Javascript has always been a bit crazy in many ways - Boolean("false") is true. Therefore you'd test if it was a string and handle "true". JSON (I'm pretty sure) parses "true" to true. I'm suggesting Node Red should do the same, purely for convenience and it's logical.

Your C# example is converting a string to a boolean, and only at the explicit request of the programmer, not automatically performing the opposite conversion (boolean to string) without the explicit request of the programmer.
In JSON everything is a string.

Haha, I never even noticed that there IS NO boolean selection on the switch node value pulldown... that does seem like it would be a reasonable thing to add -- of course, then getting the backend logic to do the right thing would be the next challenge!

This i due to the fact that equality comparisons in Javascript (and therefore, in Node-RED, too) are at best confusing, and at worst just deceptive! Check out Dorey's github site for a summary of all the "loose" (==) and "strict" (===) equality operators evaluate for all different data types...

1 Like

Not in the values Look at the rules (tripped me up a number of times too)

This is the point I'm trying to make - people are going to get tripped up all the time, and do as I did and use = "true". My preference would be to (1) include Boolean as an option, but also (2) support the specific cases of "true" being true and "false" being false, since they're logical and make NR more accessible to the inexperienced. But don't get hung up on (2), when (1) is better anyway.

1 Like