Set element's custom state on condition?

Can this be done? It appears not.

It seems perfectly reasonable that one might want to alter the custom state of an element based on a condition; yet the choices are restricted to the mostly visible properties/attributes of an element - e.g. font size, color, visibility, etc.

The ability to set a custom state would be truly useful. Am I overlooking something?

2 Likes

Yeah unfortunately the set state operator at the moment is only available through workflows.

But yes, I agree it would be nice to have the inclusions of setting a state on an element with the elements conditional properties. Such as ā€˜When this group is hoveredā€¦ā€™ set state to x or ā€˜When this input is focusedā€™ā€¦
set state to x.

There is a hack workaround for setting a state on a element in relation to a condition, but it is limited. For instance you could have the element invisible then set a condition to make it visible, then you can use the workflow ā€˜When condition is trueā€™ > ā€˜When x element visibleā€™ set state to x. This is only handy if a few scenarios though such as dropdown menus.

Anyway, might be worth checking if the idea is posted for this, Iā€™m sure its been mentioned in the past, but might be worth bringing back to life if the post is dated as its a fair request.

2 Likes

Thanks for the reply, @luke2. Thatā€™s exactly what I wound up doing - i.e. using the visibility property.

In my case, though, I wanted to change properties on multiple elements in response to the same ā€œconditionā€. Turns out the condition is a rather lengthy dynamic expression involving a database look-up, and I wanted to adhere to the DRY (donā€™t repeat yourself) principle instead of entering same lengthy expression over and over again. It would also simplify maintenance since there would be one place to update the expression if need be.

So I thought a single custom state containing the result of the expression could be referenced in each elementā€™s condition, but no go. Using the invisibility property of one of the elements worked in this situation, but itā€™s not as ā€œsemantically cleanā€. Anyway, Iā€™ll post it as a suggestion.

Hello folks,

Three years later, here am I in the exaclty same situation of @sudsy : I want to change a property on multiple elements in response to the same heavy condition and want to avoid repeating the DB look-up multiple times.

I thought about using a hidden text field that its content would be conditionally changed. Then refeer to this textbox content as a condition to differents elements. Like a variableā€¦ But Iā€™m a bit cautious about someone changing the content of this text-box manually using browser element inspector. Is this a real issue?

After 3 years, do anyone suggest another approach to it?

Thanks!

Canā€™t remember the details of what I was trying to solve at the time, but would the Do when condition is true workflow help you at all?

1 Like

Thanks for quick response!

Uhmmmmm, I think soā€¦ Basically I have a couple of elements that should hide or show, change color and font, based on a condition. This condition is composed by a pair of ā€œDo searchā€ operations that, idk, doesnā€™t make sense to be repeated at each element.

Ideally, I would like to set a ā€œstateā€ to a group and, based on that state, the elements would behave accordingly.

I guess I can use ā€œDo when condition is trueā€ to set the state that will be used in ā€œwhenā€ conditions of all elements. It would be N workflows (in my case, N = 5), each of them with their ā€œOnly whenā€ condition, that will trigger a state change of the outter group. All the elements will have conditions pointed to this outter group state and will behave accordingly.

I have no clue of how often Bubble run the condition query at workflow level to check if the conditions are match (and trigger the workflow). Maybe if it keeps running it indefinitely, I might be overcomplicating and achieving the same undesired effect (running multiple times a condition query that could run only once).

Thanks for the suggestion, Iā€™ll test it anyway!

Sounds like a good approach.

FWIW, I also use it at times to detect when a custom stateā€™s value has changed.

1 Like