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
Hello, how can I manage the NaN value coming from a Home Assistant sensor?
It happens when I restart HA.
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
= 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?
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
Of course this would be a breaking change
As for testing
isNaN - thats a reasonable suggestion
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
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
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)
TBH, I assumed it would return true since
typeof NaN returns
Suppose someone should test it
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!
But what are we actually testing ? - we don't test for typeof NaN afaik.
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.
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
So the suggestion was
So the issue is when a payload contains NaN and the user wishes to
What Nick said
That is probably the right answer, to be highlighted as a breaking change in 3.0
How would one test for
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.
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.
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.
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
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
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
No - they'd just have to redo their switch node - the new node would be a superset of the old one
Okay - so with your low-code/no-code evangelist hat on, what is the scenario where you need to know you have