Indeed - I thought one of the ideas of Node-RED (and low code) was to insulate users from quirks of the underlying language... If users are using the low code (nodes) we should try to follow human expectations - if you want to play with the details of the language then you can always use a function node.
PS - I'm absolutely not against tidying up / changing the current list of options...
If the flow relies on the fact that NaN is considered to be of type Number then how would they configure a switch node to let through numbers and NaN, but not other types?
The thread in the OP was the one that brought it up
But if this is the only message that the switch node cannot deal with - then it should be added as a matter of principle.
The most obvious use for it is if a preceding node ended up outputting NaN as a result of a div by zero operation
and
I'm all for the low-code elements not following the underlying JS behaviour but being understandable and easy to use as uniquely Node-RED "language" concepts/structure
However, in this case - "type of" (I'm assuming) directly maps to the JS type of test? (if this is wrong then ignore rest of post)
So, for consistency, I think it might be wrong to override that just for NaN
Alternatively, we could do a little subterfuge under the hood and let the ==/!= tests treat the string "NaN" as the test value as being special and look for both NaN and "NaN"
But why would a test for 'not of type number' be insufficient? Why do you need to know you explicitly have NaN?
I'm losing you a bit here
Currently, we can't test for NaN in a switch node
So any NaNs are just treated as valid Number types. Only people using JSONata or regexes can detect them in a switch node and all such nodes would still work without modification
I'm saying leave type of testing alone to just deal with JS types (as I believe it currently does)
Actually that gives INFINITY, not NaN.
As you can tell from my initial post above I (as a not so great JS programmer) didn't realise NaN was a number - I'd assumed that is of type number would DO THE RIGHT THING. As for the OP - they only want to pass through valid numbers - so if it did the "right" thing then that test would work fine.
As you know, my JS knowledge is very weak but ...
NaN is a very specific value
In JS, it's considered to be a valid number but of course, once some previous node has produced it - I can easily imagine it causing problems further down a flow
But my fundamental point is - someone has encountered it in a real world scenario and can't deal with it unless they use code.
Its a great testament to the current NR nodes and flows that this hasn't been noticed before now 
But it probably has by JS coders and they've just sorted themselves out
It's no more esoteric than null or empty and we have options to deal with them (as an aside - is empty the same as JS undefined?)
Well now we need two extra tests in that case
I've lost what you think what doing what would be the right thing? 
I think Dave's point is that if what that person required was to test for a valid number then is of type Number (where NaN is considered not a number) would do it without code. The time when code would be required changes to wanting specifically to test for NaN.
What are you saying?
Are you saying the node can currently deal with NaN?
Are you saying that the "type of" option should be modified to exclude NaN as a being of type Number?
Or something else?
It seems to me to come down to how NaN and Infinity are treated by JS and whether we want to replicate that in the node or to have something different that may make sense to "normal" people (e.g. not us! 
).
Thinking through the whole thread, I'd be inclined to come down on the side of having an "Is Number"/"Is Not Number" and then also having NaN and INFINITY as separate tests. In other words sticking with the JS usage. Largely because these are edge cases and if you ended up with one of them you would most likely have needed to look up what they mean anyway.
I can only remember one occasion when I had to check for NaN. I would normally try to understand whether an input that must be a number may not be (mostly user inputs) and put in a check to prevent it. So testing for the input rather than testing the output. But I understand that beginners or non-programmers might miss that.
If I were designing this from scratch, I think that I would use the "Type Of" option in a human sense not a JS sense and build these options into that feature. It is possible that doing it that way now might also give the best backwards compatibility?
And that is what is being discussed - modifying the NaN edge case so it isn't treated as a number by the type test.
Yes it would break a flow that wanted to allow through both numbers and NaN. But this goes back to the question I posed - can anyone conceive of a non-contrived scenario where a flow relies on that?
We certainly have scope to make this change in 3.0. And I would argue the risk of breaking real flows is tiny so it can be considered rathe than automatically dismissed as we would do in non-major releases.
Did you notice this suggestion from earlier?
I.e leave type of testing alone and modify the == and != instead.
That feels far more hacky to me and requires the user to know about NaN as some magic string. So no, that wouldn't get my vote.
This topic was automatically closed 60 days after the last reply. New replies are no longer allowed.
Copyright OpenJS Foundation and Node-RED contributors. All rights reserved. The OpenJS Foundation has registered trademarks and uses trademarks. For a list of trademarks of the OpenJS Foundation, please see our Trademark Policy and Trademark List. Trademarks and logos not indicated on the list of OpenJS Foundation trademarks are trademarksā¢ or registeredĀ® trademarks of their respective holders. Use of them does not imply any affiliation with or endorsement by them.
The OpenJS Foundation | Terms of Use | Privacy Policy | OpenJS Foundation Bylaws | Trademark Policy | Trademark List | Cookie Policy