[FEATURE REQUEST]Add more options to the switch node

[cymplecy]

For a long time, I've been thinking that the switch node (one of NRs fundamental core nodes) needs at least some more options/bit of a redesign

Since there are rumours of a Version 3 coming soon I thought I'd ask for some little things (and maybe some big things as well )

e.g. in

Manage a NaN value

Hello, how can I manage the NaN value coming from a Home Assistant sensor? It happens when I restart HA. [image] Thankyou

the need to detect NAN has come up

I can't see a non-coding way of doing it at moment so could it be added to the node?

And then brings me to the main issue - lack of consitency in not having NOT options for all the options

We have:
= and !=
All the >, >=, < and <= options
true and false
is null and is not null
is empty and is not empty

But we don't have:
does not have key
is not between
does not contain
Is not of type

We don't have does not match RegEx but since RegEx itself can handle that (I assume) then not an issue

And needing is NaN and is not NaN also now

So can we have those adding please?

[Steve-Mcl]

@cymplecy

But we don't have:
does not have key
is not between
does not contain
Is not of type

Perhaps a better request would be to reduce the number of items in the list and add a negation option.
e.g. instead of is empty and is not empty we have only is empty and a not choice
Of course this would be a breaking change

As for testing isNaN - thats a reasonable suggestion

[cymplecy]

As I said, I'm starting with the simple stuff 1st

A not option is my preferred solution but that requires a substantial change and a bit of work in handling the transition for existing nodes to a new format with an extra option.

The upgrade path HAS to be as faultless as possible

[cymplecy]

@Steve-Mcl

Of course this would be a breaking change

I don't think it can be a breaking change - the code that handles the change needs to be able to convert between the old method and the new method.

I don't see this as being particularly difficult but it HAS to be got right

[dceejay]

For NaN can't you just test for "is of type" number and then have an "otherwise" just below.
(would also work for the other negatives)

[Steve-Mcl]

@dceejay

For NaN can't you just test for "is of type" number

TBH, I assumed it would return true since typeof NaN returns "number"

Suppose someone should test it

[cymplecy]

@dceejay

and then have an "otherwise" just below.
(would also work for the other negatives)

Of course, any option can use that approach

But, it's inconsistent depending on what type of test your using

And it doesn't look nice having unused switch outputs (this will be discussed further down the thread when I ask for the big FR!

[dceejay]

@Steve-Mcl

typeof NaN returns "number"

But what are we actually testing ? - we don't test for typeof NaN afaik.

[knolleary]

We already have the requirement to allow for compound rules - tests against multiple properties with AND/OR conditions. That will drive a much larger underlying change to the node properties.

Modifying the list of available options will be trivial in comparison.

Whether we end up with a list of all is FOO and is not FOO, or simplify the list to just is FOO and then a not modifier than can be applied is something to consider as part of the UI rework needed. The downside is discoverability - knowing to select the is FOO option and then being able to negate it.

The current approach of adding two rules - is FOO then otherwise is a workaround that leaves you with unused ports on the node that you have to remember to ignore.

[knolleary]

@dceejay

But what are we actually testing ? - we don't test for typeof NaN afaik.

If some code has parsed a string to a number, it could create the value NaN. The requirement is to detect that case. You cannot use is type because typeof NaN is number.

[Steve-Mcl]

@dceejay

we don't test for typeof NaN afaik

@cymplecy stated

@cymplecy

the need to detect NAN has come up

I can't see a non-coding way of doing it at moment so could it be added to the node?

So the suggestion was

@cymplecy

And needing is NaN and is not NaN also

So the issue is when a payload contains NaN and the user wishes to

What Nick said

[dceejay]

ah right.. so surely the fix would be to fix our "is of type" number test to report that as false - so it is as normal humans would expect (rather than Javascript programmers). ?

[knolleary]

@dceejay

so surely the fix would be to fix our "is of type" number test to report that as false

That is probably the right answer, to be highlighted as a breaking change in 3.0

[Colin]

@dceejay

so surely the fix would be to fix our "is of type" number test to report that as false

How would one test for is NaN?

[knolleary]

@Colin

w would one test for is NaN?

True - the question is then, is there a not completely artificial use case for wanting to know you have NaN specifically, rather than it not being a number value?

I can't think of a time when I've ever wanted to know I have NaN, rather than know I don't have a number.

If we have NaN in the UI, then we have to explain to users what that means. And frankly, I doubt that is worth the effort or needed at all.

[Colin]

@knolleary

is there a not completely artificial use case for wanting to know you have NaN specifically, rather than it not being a number value?

Also are there any use cases for the inverse - wanting to allow NaN through as it is (correctly) of type Numeric.
There is also the case of INFINITY to consider.

[Colin]

I am nervous about making a breaking change to the Switch node where, if anyone does have a flow that will be broken, the only solution is to use a Function node.

[cymplecy]

@knolleary

I can't think of a time when I've ever wanted to know I have NaN

See thread ref in OP

I think that NaN as a value is a fairly valid JS concept so I think it should be able to be dealt with without having to code

I'd assume that all other users that have encountered the need have simply programmed it

As you know - I'm a low/no-code evangelist

@dceejay

so surely the fix would be to fix our "is of type" number test to report that as false - so it is as normal humans would expect (rather than Javascript programmers). ?

I'm not the JS person here but I thinking "is of type" does mean whatever type means in JS and not what muggle humans think it means

So I'd stick to "is of type" having one-one relationship with what JS uses

[cymplecy]

@Colin

I am nervous about making a breaking change to the Switch node

Its up to devs whether to have the ease of programming new behaviour but it be a breaking change or go to the trouble of making sure it doesn't break existing flows

@Colin

if anyone does have a flow that will be broken, the only solution is to use a Function node.

No - they'd just have to redo their switch node - the new node would be a superset of the old one

[knolleary]

@cymplecy

I think that NaN as a value is a fairly valid JS concept so I think it should be able to be dealt with without having to code

Okay - so with your low-code/no-code evangelist hat on, what is the scenario where you need to know you have NaN?

There are some ugly bits of the JavaScript language and we shouldn't just blindly require end users to understand them. We don't always get it right, but we do give it some proper consideration.