Invisible elements with conditional formatting flash on page load

I created a super simple example of the issue I am seeing. https://helpexamples.bubbleapps.io/

In my larger app, when I have a element that is not visible on page load, and conditionally visible depending on a custom state for the page, when the page first load, the invisible elements appear for a second and then disappear. It is significantly noticeable when using the editor and previewing, and I thought it was probably the overhead of the debugger, etc. but after creating this example and publishing it,the issue still occurs.

In my example Items 1 and 2 are visible on page load, but item 3 is invisible and conditionally visible if the custom state editMode is set to “no”. In the page load, I set the editMode state to “yes” so the element should not appear, yet it flashes anyway.

Shouldn’t I never see element 3?

Does anyone have any insight into why this is happening or whether I am misunderstanding the way this is supposed to work.

If you don’t see it happen on page load, hit F5 and you should.

Thanks,

Marc

Hi Marc :slight_smile: It sounds like you have everything set up correctly! I don’t think that element should flash as well. Can you temporarily set the helpexamples app to public and share a link to the editor?

It seem to me that sometimes what happens is that it’ll run the conditional calculation on, say, a custom-state that is still null (because it hasn’t loaded yet) which causes the condition to be met temporarily, until the custom-state’s value is set.

It’s one possible explanation. I wouldn’t be surprised if there are more.

1 Like

I have set the app to public. Here is the link to the editor. https://bubble.io/page?name=index&id=helpexamples&tab=tabs-1
Thanks

sridharan,

That would seem to defeat the purpose of conditional formatting if that was true. Hopefully there is a solution.

You can always add “and page loaded (entire) = yes” to the condition. This way, it’s only true once everything has loaded.

Just a thought. Of course, this is only a solution if the problem I mentioned is, in fact, the problem you’re running into. Looks like someone else is playing with your demo (I assume it’s Faye) and I’m sure she’ll have some great suggestions too.

3 Likes

Scott’s solution is the way to go! :slight_smile: I hadn’t thought of that, and was going to suggest adding “and [custom state’s] value is not empty” to the condition, but that option is not available for yes/no states. There’s a new page in the app now called “clone” where the condition is added “and page loaded ‘entire’ is yes”:

Preview:
https://helpexamples.bubbleapps.io/version-test/clone

Editor:

3 Likes

My thanks Faye and Scott.

At first I did not think the solution worked because in preview mode the “flash” still happens, but I imagine that is because of the overhead of the debugger. In the released version, the flashing element is gone.

Marc

2 Likes

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:

  1. 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.

  2. 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.

  1. 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”

  1. 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.

conditional format setting refresh

  1. 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.

conditional format setting items

  1. 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.

  1. NULL value custom states should not evaluate to “no”/“false”.

  2. 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.

  1. The should be a “pre load” workflow event.

  2. 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

2 Likes

So the response to my bug was that NULL evaluates to NO for booleans (Yes/No types) and that is by design. There are some easy workarounds, like setting the value of the custom state as the first step in a page load workflow OR not using a boolean custom state and instead creating a text based boolean (“Yes”/“No”) because when looking for “contains ‘no’” a null value is not a match.

As I reflect on the design I think it is often standard to evaluate NULL as no hence all the isNULL functions in databases etc. so I don’t think my first two solution ideas are good ones after all.

It does seem to me however that this is a perfect example of why default custom state values that are loaded “server side” are necessary.

1 Like

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