I am re-opening this because I think there is still a bug going on here. I have a brand new example page that is more realistic (does database access) and here is what is going on. This is a lot of info here, but it will help find the issue.
The page in question can be found here âliveâ https://helpexamples.bubbleapps.io/loadvisibility
and here for editing helpexamples | Bubble Editor
On the page called loadVisibility I have the following:
-
I have a group called âItemsâ that contains a repeating group and two text elements in the RG. The data source for the repeating group is a table called testLoads which has records that have a name and an active bit. The source is a simple search for testLoads records. The RG and the text elements are set to be visible on page load. The group called "Itemsâ is set to NOT be visible on page load.
-
I have a group called âRefreshâ that contains a text element and a button. The text element and the button are set to be visible on page load. The group called "Refreshâ is set to NOT be visible on page load.
- I have a workflow on page load that sets a page custom state called âhasItemsâ to âyesâ ONLY when a SEARCH for testLoads where active=âyesâ returns any records (count > 0). So if there are records in the table where active is set to âyesâ than the custom state called âhasItemsâ is set to âyesâ
- I have conditional formatting on the group called âRefreshâ that says if the custom state of the page, hasItems, is ânoâ AND the Page loaded (entire) is âyesâ then make the element visible. So this SHOULD mean, wait until the page loads completely and then IF hasItems is ânoâ then show this group.
- I have conditional formatting on the group called âItemsâ that says if the custom state of the page, hasItems, is âyesâ AND the Page loaded (entire) is âyesâ then make the element visible. So this SHOULD mean, wait until the page loads completely and then IF hasItems is âyesâ then show this group.
- Finally, I have a single record in the database that has the active bit set to âyesâ.
So with all of this, and how I understand things to work, this is what should happen.
Both groups are set to NOT be visible on page load, so any elements contained in those groups should also not be visible. Therefore, when this page load, NEITHER group should be visible at first. On page load, the workflow should set the hasItems custom state to âyesâ because there is a row in the database that has itâs active bit set. Once the page loads entirely, the conditional evaluations should happen and the Items Group should see that the hasItems state is âyesâ and should become visible. The Refresh Group should see that the hasItems state is âyesâ (and therefore not ânoâ) and should remain invisible.
What is happening instead is the Refresh Group is showing up for a quick second and then hiding itself.
Here is my presumption as to what is going on. I think the conditional validation is happening before the Page Load workflow is complete AND I think that it evaluates NO value to mean the same thing as ânoâ.
So from my perspective, something is not working as expected though what the right solution is, I am not sure.
BTW, I did a second test of this with a different custom state that was a âtextâ type instead of a boolean (yes/no) and the same issue happened. You can see that here https://helpexamples.bubbleapps.io/loadvisibility2 and helpexamples | Bubble Editor
Any one of the following seem like solutions.
-
NULL value custom states should not evaluate to ânoâ/âfalseâ.
-
Conditional formatting evaluation should not short circuit upon a null value. If the conditional says (only when value is âyesâ ) then ANYTHING other than âyesâ should not trigger the condition.
3.There should be a prioritization of page load workflows over conditional evaluation.
-
The should be a âpre loadâ workflow event.
-
Custom states should have default values that are loaded âserver sideâ.
I am going to create a bug ticket for this because regardless of whether some of the proposed solutions seem like âfeaturesâ what I am sure of is, if I told something to not be visible until X happens, it should respect that.
If anyone can point to any simple mistakes I made in validating this, let me know.
Otherwise, @emmanuel @josh Any insight on this?
Thanks in advance,
Marc