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"?
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...
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.
Sorry to reply to an old topic. I had the same problem trying to figure out where to select the "boolean" option before I Googled for ten minutes and came upon this thread which helped me resolve the problem. The UX could stand to be fine tuned.