I have a text element with 43 Conditions. Some conditions affect the visibility of the element.
The majority of the conditions, however, change display properties (text color, shadow, background color, stroke and stroke color, etc.) These are important to my app and I need all of them.
This Text element is in a repeating group and the conditions are based on each cell’s data, often combined with other things outside of the repeating group.
The problem I am having is now that there are so many conditions, what happens is the repeating group is first rendered without the conditions, then after a short delay, the properties are changed and the conditions applied. The result is a bit of a flash which is not a good user experience.
My question is if there are any strategies for handling so many conditions on an element that change visual properties. Is there some way I can prevent the repeating group to draw the contents until after the conditions are applied?
Obviously I don’t know what you’re doing… but I’d be willing to bet there must surely be a more efficient way to do whatever it is you’re trying to do than using 43 conditions…
The changing visual of this element conveys information about the data. The conditions are testing for all of the variations. I know it sounds complex, but each of the differences are part of the core function of my app.
Personally, if ever I find myself needing to use more than 6 conditions on a single element, I’ll find a more efficient way to do things (and there almost always is one).
Do you have an example of the kind of thing you’re doing?
Some conditions control visiblity. Depending on the users actions, this element needs to become hidden.
There are more conditions to control items such as margins so that the element’s position remains fixed when other elements in the row become visible/hidden. This happens most often when changing pages or when the row is hovered.
Each of these has meaning that my users will understand at a glance.
The conditions vary. Some are simple but some are also complex. They can test against a user preference, a date, the value of a state on the page, or fields of the row’s data. I’m not going to list all of it out here because it’s too much.
For example, the background will be yellow when a field in the data is “yes”. The background will be blue when the value of a state on the page matches a field in the data on the row. And it will be a yellow-blue gradient when both conditions are true.
When there are so many variations, are there better ways to handle all the conditions?
I also don’t understand the use case. Fundamentally, why are you formatting text in dozens of ways based on various filters? I guarantee it won’t be intuitive to users and will look messy. You’re saying that users will understand 12+ different text styles at a glance which just wouldn’t be the case.
If it’s really essential, you can probably optimise through using reusable element properties and formatting the text inside the RE based on its properties.
I don’t intend to defend the merits of my app or its features. I’m only asking if there are other ways in Bubble to handle multiple formatting conditions.
I can’t use workflows because they don’t alter display properties. And I don’t find any other places to put these conditions.
One of the other problems is that properties like margins are not dynamic. I have to enter a static number. This forces me to create a separate condition for every possible situation.
Come up with whatever lumping logic that works for you.
Let’s say that you came up with one that allows you to have about 6 lumps of 6-7 conditions each.
Create a hidden popup that you will never open and add 6 groups of type yes/no.
The following labeling for each group is just for illustration purposes:
var 1of6 - are conditions 1,2,3,4,5,6 yes?
var 2of6 - are conditions 7,8,9,10,11,12 yes?
etc etc until you get to var 6of6 - are conditions 37,38,39,40,41,42,43 yes?
Build the necessary expressions on each var in order to achieve a yes or no answer.
Now you “brought down” the complexity from 43 to 6
Use the vars as needed (hopefully you will not need “Only when var1of6 is yes and var2of6 is yes and var3of6 is yes and var4of6 is yes and var5of6 is yes and var6of5 is yes” … but this will also work)
The above aims to provide you with a framework to simplify logic … if at all possible.
But that’s because you’re fixed in deciding exactly how you want something displayed. In reality, you have to consider execution when you’re developing your app. You have to design your app with web development best practices in mind rather than solely the result, because that’s what Bubble’s designed for.
Update: It turns out that the 43 conditions are not what was causing the visual flash. In fact, everything displays instantly correctly.
The problem came from a different element on the repeating group row which also had about 10 conditions, but was using CSS to help display dynamic widths. When I disabled this particular element, the display is very smooth.
So I need to adjust that one element.
But I’d still like to know of other strategies for managing many conditions on an element. The interface for this is quite cumbersome in addition to the other reasons I mentioned.
Probably with an option set of different classes/styles, and then just filter them based on the various criteria, and apply the relevant classes to each element.
I’d image you wouldn’t need a single condition doing it that way if you were logical enough with your styles and filtering.
