In Bubble, to show or hide an element based on the result of a logic expression, I have to specify it two times, one straight and one negated.
Sometimes this gets inconvenient, because I by mistake negate the logic expression incorrectly (especially if it contains a lot of “and…” or “or…”). Or, usually, I copy and paste the expression, negate it (which is not always straightforward) and then when I later update it, I forget to update also the negated one.
Is there a way to tell Bubble that the visibility of an element is directly the result of the expression.
In other words, if the expression’s result is “yes”, the element is visible, otherwise it isn’t.
Hi, I’m not understanding why you need the 2nd condition. Make sure ‘The element is visible on page load’ is unchecked and then your first condition does everything you need, no?
1 Like
That works if the element is to be toggled once. But if you remove one of the two conditions, there’s no way to make it visible (or hidden) again.
It should work fine. When the state is set back to ‘no’, it should hide. Here’s an example:
Editor: https://bubble.io/page?type=page&name=toggle&id=phil-testing&tab=tabs-1
Preview: https://phil-testing.bubbleapps.io/version-test/toggle?debug_mode=true
1 Like
That’s interesting. I’m almost sure I’ve done the two conditions thing in the past because elements didn’t reappear.
I have to redo some tests.
This wasn’t immediately apparent to me when I started with Bubble…it finally dawned on me that for these conditions (as well as the workflow events) to work, there has to be a “change of status”. In the example you show above, if you have the element set as visible on page load, and then have a condition that only changes to visible yes, there will never be a change of status – it starts visible, and then can only ever be set to visible. However if you use Phil’s method, and set the element to NOT be visible on page load, and then track a condition to move it visible, you will get the desired impact of toggling, because you’ve setup a situation that can change back and forth. You can also do the reverse.
For event workflows, I remember having a value > 0 type condition and wondering why it wouldn’t trigger when the value went from 5 to 10 – it is because to trigger this, it has to first NOT be > 0.
So we are guaranteed that if a condition fires, it will fire in the reverse direction too?
That would save me so much typing
Because that’s what I’m doing now:
I’ll leave it to Bubble to provide guarantees 
, but that’s how I look at it yes.
I hereby guarantee, except when using Safari, that hidden …
oh I must have choked, I couldn’t finish it either 
1 Like
This topic was automatically closed after 70 days. New replies are no longer allowed.