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