# \[FEATURE REQUEST\]Add more options to the switch node

**URL:** <https://discourse.nodered.org/t/feature-request-add-more-options-to-the-switch-node/57489>\
**Category:** General\
**Created:** [30 January 2022 09:00 UTC](https://discourse.nodered.org/t/feature-request-add-more-options-to-the-switch-node/57489 "2022-01-30T09:00:15Z")\
**Posts on this page:** 20\
**Page:** 1

<div class="post-metadata">

**Author:** ![cymplecy](https://sea2.discourse-cdn.com/flex026/user_avatar/discourse.nodered.org/cymplecy/32/2773_2.png) [@cymplecy](https://discourse.nodered.org/u/cymplecy)\
**Post date:** [30 January 2022 09:00 UTC](https://discourse.nodered.org/t/feature-request-add-more-options-to-the-switch-node/57489/1 "2022-01-30T09:00:15Z")

</div>

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](https://discourse.nodered.org/t/manage-a-nan-value/57440):
>
> Hello, how can I manage the NaN value coming from a Home Assistant sensor? It happens when I restart HA. 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  
 ![image](https://us1.discourse-cdn.com/flex026/uploads/nodered/original/3X/d/1/d1aea3ad1c50771337024531c5571bc23d1e5ee2.png)

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?

---

<div class="post-metadata">

**Author:** ![Steve-Mcl](https://sea2.discourse-cdn.com/flex026/user_avatar/discourse.nodered.org/steve-mcl/32/4826_2.png) [@Steve-Mcl](https://discourse.nodered.org/u/Steve-Mcl)\
**Post date:** [30 January 2022 09:41 UTC](https://discourse.nodered.org/t/feature-request-add-more-options-to-the-switch-node/57489/2 "2022-01-30T09:41:29Z")

</div>

> [@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 🙂

---

<div class="post-metadata">

**Author:** ![cymplecy](https://sea2.discourse-cdn.com/flex026/user_avatar/discourse.nodered.org/cymplecy/32/2773_2.png) [@cymplecy](https://discourse.nodered.org/u/cymplecy)\
**Post date:** [30 January 2022 09:47 UTC](https://discourse.nodered.org/t/feature-request-add-more-options-to-the-switch-node/57489/3 "2022-01-30T09:47:45Z")

</div>

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

---

<div class="post-metadata">

**Author:** ![cymplecy](https://sea2.discourse-cdn.com/flex026/user_avatar/discourse.nodered.org/cymplecy/32/2773_2.png) [@cymplecy](https://discourse.nodered.org/u/cymplecy)\
**Post date:** [30 January 2022 09:49 UTC](https://discourse.nodered.org/t/feature-request-add-more-options-to-the-switch-node/57489/4 "2022-01-30T09:49:55Z")

</div>

> [@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 🙂

---

<div class="post-metadata">

**Author:** ![dceejay](https://sea2.discourse-cdn.com/flex026/user_avatar/discourse.nodered.org/dceejay/32/38_2.png) [@dceejay](https://discourse.nodered.org/u/dceejay)\
**Post date:** [30 January 2022 09:54 UTC](https://discourse.nodered.org/t/feature-request-add-more-options-to-the-switch-node/57489/5 "2022-01-30T09:54:10Z")

</div>

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)

---

<div class="post-metadata">

**Author:** ![Steve-Mcl](https://sea2.discourse-cdn.com/flex026/user_avatar/discourse.nodered.org/steve-mcl/32/4826_2.png) [@Steve-Mcl](https://discourse.nodered.org/u/Steve-Mcl)\
**Post date:** [30 January 2022 09:57 UTC](https://discourse.nodered.org/t/feature-request-add-more-options-to-the-switch-node/57489/6 "2022-01-30T09:57:24Z")

</div>

> [@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"`  
 ![image](https://us1.discourse-cdn.com/flex026/uploads/nodered/original/3X/8/4/84ddea73a55f43e97c57723236d4450c8cb16ffb.png)

Suppose someone should test it 😃

---

<div class="post-metadata">

**Author:** ![cymplecy](https://sea2.discourse-cdn.com/flex026/user_avatar/discourse.nodered.org/cymplecy/32/2773_2.png) [@cymplecy](https://discourse.nodered.org/u/cymplecy)\
**Post date:** [30 January 2022 10:10 UTC](https://discourse.nodered.org/t/feature-request-add-more-options-to-the-switch-node/57489/7 "2022-01-30T10:10:34Z")

</div>

> [@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! 🙂

 ![image](https://us1.discourse-cdn.com/flex026/uploads/nodered/original/3X/0/b/0bc57f66586ddf0f48f05d44e7f8d33c3029630d.png)

---

<div class="post-metadata">

**Author:** ![dceejay](https://sea2.discourse-cdn.com/flex026/user_avatar/discourse.nodered.org/dceejay/32/38_2.png) [@dceejay](https://discourse.nodered.org/u/dceejay)\
**Post date:** [30 January 2022 10:19 UTC](https://discourse.nodered.org/t/feature-request-add-more-options-to-the-switch-node/57489/8 "2022-01-30T10:19:17Z")

</div>

> [@Steve-Mcl](#):
>
> `typeof NaN` returns `"number"`

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

---

<div class="post-metadata">

**Author:** ![knolleary](https://sea2.discourse-cdn.com/flex026/user_avatar/discourse.nodered.org/knolleary/32/3_2.png) [@knolleary](https://discourse.nodered.org/u/knolleary)\
**Post date:** [30 January 2022 10:20 UTC](https://discourse.nodered.org/t/feature-request-add-more-options-to-the-switch-node/57489/9 "2022-01-30T10:20:43Z")

</div>

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.

---

<div class="post-metadata">

**Author:** ![knolleary](https://sea2.discourse-cdn.com/flex026/user_avatar/discourse.nodered.org/knolleary/32/3_2.png) [@knolleary](https://discourse.nodered.org/u/knolleary)\
**Post date:** [30 January 2022 10:22 UTC](https://discourse.nodered.org/t/feature-request-add-more-options-to-the-switch-node/57489/10 "2022-01-30T10:22:28Z")

</div>

> [@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`.

---

<div class="post-metadata">

**Author:** ![Steve-Mcl](https://sea2.discourse-cdn.com/flex026/user_avatar/discourse.nodered.org/steve-mcl/32/4826_2.png) [@Steve-Mcl](https://discourse.nodered.org/u/Steve-Mcl)\
**Post date:** [30 January 2022 10:23 UTC](https://discourse.nodered.org/t/feature-request-add-more-options-to-the-switch-node/57489/11 "2022-01-30T10:23:47Z")

</div>

> [@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 ☝

---

<div class="post-metadata">

**Author:** ![dceejay](https://sea2.discourse-cdn.com/flex026/user_avatar/discourse.nodered.org/dceejay/32/38_2.png) [@dceejay](https://discourse.nodered.org/u/dceejay)\
**Post date:** [30 January 2022 10:29 UTC](https://discourse.nodered.org/t/feature-request-add-more-options-to-the-switch-node/57489/12 "2022-01-30T10:29:10Z")

</div>

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). ?

---

<div class="post-metadata">

**Author:** ![knolleary](https://sea2.discourse-cdn.com/flex026/user_avatar/discourse.nodered.org/knolleary/32/3_2.png) [@knolleary](https://discourse.nodered.org/u/knolleary)\
**Post date:** [30 January 2022 10:31 UTC](https://discourse.nodered.org/t/feature-request-add-more-options-to-the-switch-node/57489/13 "2022-01-30T10:31:46Z")

</div>

> [@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

---

<div class="post-metadata">

**Author:** ![Colin](https://sea2.discourse-cdn.com/flex026/user_avatar/discourse.nodered.org/colin/32/17040_2.png) [@Colin](https://discourse.nodered.org/u/Colin)\
**Post date:** [30 January 2022 10:34 UTC](https://discourse.nodered.org/t/feature-request-add-more-options-to-the-switch-node/57489/14 "2022-01-30T10:34:19Z")

</div>

> [@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?

---

<div class="post-metadata">

**Author:** ![knolleary](https://sea2.discourse-cdn.com/flex026/user_avatar/discourse.nodered.org/knolleary/32/3_2.png) [@knolleary](https://discourse.nodered.org/u/knolleary)\
**Post date:** [30 January 2022 10:36 UTC](https://discourse.nodered.org/t/feature-request-add-more-options-to-the-switch-node/57489/15 "2022-01-30T10:36:48Z")

</div>

> [@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.

---

<div class="post-metadata">

**Author:** ![Colin](https://sea2.discourse-cdn.com/flex026/user_avatar/discourse.nodered.org/colin/32/17040_2.png) [@Colin](https://discourse.nodered.org/u/Colin)\
**Post date:** [30 January 2022 10:42 UTC](https://discourse.nodered.org/t/feature-request-add-more-options-to-the-switch-node/57489/16 "2022-01-30T10:42:15Z")

</div>

> [@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.

---

<div class="post-metadata">

**Author:** ![Colin](https://sea2.discourse-cdn.com/flex026/user_avatar/discourse.nodered.org/colin/32/17040_2.png) [@Colin](https://discourse.nodered.org/u/Colin)\
**Post date:** [30 January 2022 10:47 UTC](https://discourse.nodered.org/t/feature-request-add-more-options-to-the-switch-node/57489/17 "2022-01-30T10:47:33Z")

</div>

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.

---

<div class="post-metadata">

**Author:** ![cymplecy](https://sea2.discourse-cdn.com/flex026/user_avatar/discourse.nodered.org/cymplecy/32/2773_2.png) [@cymplecy](https://discourse.nodered.org/u/cymplecy)\
**Post date:** [30 January 2022 10:59 UTC](https://discourse.nodered.org/t/feature-request-add-more-options-to-the-switch-node/57489/18 "2022-01-30T10:59:55Z")

</div>

> [@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

---

<div class="post-metadata">

**Author:** ![cymplecy](https://sea2.discourse-cdn.com/flex026/user_avatar/discourse.nodered.org/cymplecy/32/2773_2.png) [@cymplecy](https://discourse.nodered.org/u/cymplecy)\
**Post date:** [30 January 2022 11:03 UTC](https://discourse.nodered.org/t/feature-request-add-more-options-to-the-switch-node/57489/19 "2022-01-30T11:03:34Z")

</div>

> [@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

---

<div class="post-metadata">

**Author:** ![knolleary](https://sea2.discourse-cdn.com/flex026/user_avatar/discourse.nodered.org/knolleary/32/3_2.png) [@knolleary](https://discourse.nodered.org/u/knolleary)\
**Post date:** [30 January 2022 11:06 UTC](https://discourse.nodered.org/t/feature-request-add-more-options-to-the-switch-node/57489/20 "2022-01-30T11:06:46Z")

</div>

> [@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.

[Next page](https://discourse.nodered.org/t/feature-request-add-more-options-to-the-switch-node/57489.md?page=2)