Empty default yes/no state is read as "no"

Bugs
1

There is conditional on the button to turn red when the parent group state is “no”
image

the group state default value is empty
image

yet on the page load:
image

see below:

bug/ not bug?

2 Likes
2

strategic bump, anybody?

3

This is not a bug. An empty (null or undefined is the technical term) yes/no value evaluates to no.

This is also the same with programming languages such as JavaScript. A value that is null or undefined is equal to false or “no”

@keith has a great video to help clear up some confusion around Boolean values, if you’re interested.

2 Likes
4

I don’t know why it me took so long to bump into this thing :stuck_out_tongue:

Thanks a lot!

1 Like
5

To expand on @tim12333’s almost entirely correct answer (and thanks for the shout-out):

The boolean (“yes/no”) datatype in Bubble is the JavaScript boolean datatype. They are identical.

Further, Bubble also inherits JavaScript’s notion of loose equivalence, to a degree.

(In JS. we can ask, “are two things equal?” In a couple of different ways — loosely or strictly. In loose equivalence, we are checking if the VALUE of two things is “the same”, regardless of data type [for this to be possible we must make some assumptions about what “equivalence” means — as one example, in loose equivalence, the string “2” is assumed to be equivalent to the number 2, and so the expression “2” == 2 evaluates to true]. In strict equivalence, we are checking if both the VALUE and the TYPE of two things is the same. Continuing our example, asking “2” === 2 (the triple equal sign is the strict equivalence operator) evaluates to false, because “2” is of type string and 2 is of type number.)

Now, what about when one of our arguments is of boolean type, but the other is of some other datatype? Obviously, in strict equivalence, the values are never the same.

But in loose equivalence, they may be the same. Certain values of other datatypes are interpreted as true and others are interpreted as false.

(When JS automatically converts a value to some other type, we call this “type coercion”.)

We might say (and, in fact, we do say) that non-boolean JavaScript values are either “falsey” or “truthy”. They are not strictly true or false, but they loosely evaluate to one or the other.

It is easiest for us to ask, “What things in JavaScript are falsey?” as the number of these things is finite. (The number of truthy things in JavaScript is nearly infinite!)

FUN FACT: There are only 7 falsey values in JavaScript! WHOA!

So here are the things that are falsey in JavaScript (meaning that, in a loose boolean comparison context, they resolve to false):

  • The special keyword/value null. Null is not its own datatype (it’s an “object” in JS terms), but it might as well be. Null is not EXACTLY the same as a Bubble’s “empty”, but all “empty” values in Bubble evaluate to null in JavaScript (e.g., when they are sent to a custom plugin, we seem them as nulls).

  • The special datatype undefined (which has no value and represents things that have no value and, as a result, cannot be said to have any other datatype).

  • The number 0 (zero). All other numbers evaluate to true. But 0 is considered false. There’s also a large integer type in JS called BigInt and 0n (the zero in the BigInt type) is considered false.

  • The keyword/value NaN (“not a number”). NaN is the result of undefined mathematical operations like zero divided by zero or “keith”/5. It is considered false. Though it might be confusing, the TYPE of NaN is number! (WHUT? Not a number is a number!? :man_shrugging:)

  • A string that is entirely empty of characters. We could type it as ‘’ or “”. This special, zero-length string is sometimes called, “the null string” but in JS, it is neither loosely nor strictly equivalent to null. But it is “falsey”.

And that’s it! Those are the only things in JS that loosely evaluate to false. Everything else is true.

Bubble, being derived from/based on/built in JavaScript, is similar.

But while JavaScript variables can change TYPES depending upon their value, Bubble variables (by which we mean fields on a Thing, custom states, the value of expressions in expression builder fields, or the exposed states of an element or action) do not dynamically change type, but CAN hold a special value – “empty” – that is not of that specific type.

That is: empty is essentially the same thing as JavaScript’s null, but a field of any datatype can hold empty, even though empty is not, itself, of that datatype.

So, in Bubble, the value of a Thing’s field or some expression (particularly “Do a Search for… :some_item”) can resolve to empty.

(But it should be noted that nothing in Bubble is ever undefined. There’s no such thing in point-and-click languages as, to be able to select something, it must have previously been defined. So, while custom code in plugins might trigger a JavaScript error by referring to some undefined thing, there’s actually no similar problems that can befall the Bubble programmer – nothing is ever undefined. The closest we can come to that is a deleted datatype or field, but the Issue Checker immediately alerts us to this, noting that there’s a reference to a thing that used to exist, but no longer does.)

Now, because Bubble is strongly typed, we don’t have automatic type coercion. And so, any boolean expression, must actually be composed of booleans (that is, all arguments must themselves be boolean [“yes/no”] values). So, unlike JavaScript, we can’t write an expression like:

some_string_expression and some_number_expression

We must instead write:

some_boolean_expression and some_other_boolean_expression

BUT, let’s say that some_boolean_expression in the Bubble expression above resolves to empty. Well, empty is null and null is falsey. And so, the left-hand side of this Bubble expression resolves to false ("no" in Bubble terms) and, as a result, the full expression will always to false.

I write all of the above as some have noted that – in my own plugins (like List Shifter, Calendar Grid Pro, etc.) – my yes/no outputs don’t usually output an explicit “no”, but generally go to “empty”. That’s by design on my side. In Bubble, that empty value is logically equivalent to “no” so I don’t waste cycles converting empty outputs to “no” as it doesn’t cause any problems. (Except for one: If you attempt to write out the value of such a field in a text element, it will appear as ‘’ (an empty string) rather than the string “no”. But personally, I find this useful for reasons I won’t belabor here, but may talk about in a future video.

(@boston85719: :point_up: you’d asked a question over in the List Shifter thread suggesting that my use of empty instead of “no” for certain yes/no outputs was causing you trouble. That’s not the cause of your issues – the workflow you’d designed would, in fact, never execute before List Shifter would send the “initialized” event because a “Do when... some condition is no” workflow can only execute when the value of that condition changes. So a workflow that is waiting for List Shifter's Initialized is no will never trigger before List Shifter's Initialized goes to yes… because List Shifter’s Initialized starts at no. (No change has happened, so the workflow cannot trigger.)

8 Likes
6

Thanks @keith for the explanation. That clears up my issues as now I understand why I never saw a ‘no’ value and it was always empty. Plus utilizing the yes/no values for conditionals or workflows is cleared up with the idea that they must first turn from no to yes before getting recognized as a no value.

1 Like
7

That saved me from a lot of dumb questions I wanted to ask…

Thank you so much @keith! You are truly a legend!!!

1 Like
8

This topic was automatically closed after 14 days. New replies are no longer allowed.