A simple Bubble hack to avoid huge “button is clickable only if…” conditionals

[ruiz86]

Have you ever run into a situation where you have a button that should only continue when a bunch of inputs are filled in?

In many cases, when that button is saving something to the database and your inputs are marked as “This input should not be empty”, Bubble already handles everything for you. The button won’t proceed if something is missing, and when you click it, Bubble highlights the inputs that need attention. You don’t have to think about button clickability at all.

The problem usually starts when you’re not saving anything to the database.

This often happens in multi step flows, wizards, or screens where the button just moves the user to the next step. It also gets worse when you have several inputs with autobinding, or groups that become visible or hidden based on conditions. At that point, you end up creating long and painful conditionals like “when input A is empty and input B is empty and input C is empty…”, and you still need to worry about which inputs are currently visible.

This can get messy very quickly.

I recently found a small hack that makes this much simpler.

What I do is create a custom event. It can be completely empty, or it can have actions, that part doesn’t really matter. The key point is that this custom event is triggered by the button.

Inside the custom event, I add parameters and pass the values of the inputs into those parameters. I don’t save anything to the database. I don’t even need to use those values for anything else. I just make sure the parameters are filled with the input values.

By doing this, Bubble automatically treats those inputs as required for the action to run. If any required input is empty, the button won’t proceed. When the user clicks the button, Bubble also highlights the invalid inputs using the standard invalid style you already configured.

The result is that the button behaves just like a “save to database” button, even though you’re not saving anything at all.

This completely removes the need for giant conditional expressions on the button and makes flows with many inputs, autobinding, and conditional visibility much easier to manage.

Hopefully this helps someone clean up those scary button conditionals we all eventually find in apps we inherit or maintain.

[code-escapee]

Thanks for sharing.

I’ve found it much easier to handle validation with a single validation / error group that has conditionals for each field.

Each conditional controls its own message, so you can show exactly what’s wrong. Missing value vs invalid value. E.g., email missing vs email entered but not a valid email. That level of specificity gets messy fast when everything is pushed through a custom event with parameters.

It also holds up better as forms change. Adding or removing a field just means adding or removing a conditional, instead of adding parameters, sending the parameters and CE logic.

Button logic stays simple.
If the validation group is empty → continue.
If not → show the validation group.

[ruiz86]

Yeah, that was my preferred way of doing it too. But now there’s this extra option that makes it much easier. The coolest thing is that it can also handle invisible inputs.

[code-escapee]

Oh. I didn’t understand your post. Yes that works well as long as the validation error is self explanatory…

[emir.ozgun]

What is this ?, just add custom states as slugs

[ruiz86]

Doing it the way I explained in the post, you do not need to deal with validation conditionals on the button. Bubble itself handles the validation for you, just like it does when there are Create or Make changes to a thing actions.

If an input is marked as “This input should not be empty” and it is empty, the button will not be clickable. However, if that input is invisible, even if it is empty, the button can still be clicked. This is very useful for large forms with autobinding, especially when you have specific inputs that become visible or invisible based on conditions.

In practice, you simply do not need to manage this manually as long as the input is being used in some way inside the button’s workflow. The issue is that in many cases the button’s workflow only has a “next step” action, for example, and that forces you to validate the button’s “isn’t clickable” state with multiple conditions. With the approach I showed, you do not need to worry about that.

Of course, this is not the only way to do it, but it is another option, and I can say it can be very useful in certain situations.

[code-escapee]

@ruiz86

for example, and that forces you to validate the button’s “isn’t clickable” state with multiple conditions.

Yeah, agreed, there shouldn’t be validation conditionals on the button, and that’s not what I’m proposing.

In the pattern I’m describing, all validation lives on a single validation / error group via conditionals. The button stays dumb. It just checks whether that group is empty or not.

Your approach works well, especially with autobinding and visibility. The difference is that this approach gives explicit control over which rule failed and why. So you can determine and message for missing value vs invalid value or multiple rules on the same field or multi field conditional validation…

[boston85719]

Just set input to should not be empty, then whatever workflow the button triggers, if it uses inputs value, the button will show as not clickable but when clicked, if any input is empty will set focus to that input

[randomanon]

@ruiz86

In many cases, when that button is saving something to the database and your inputs are marked as “This input should not be empty”, Bubble already handles everything for you. The button won’t proceed if something is missing, and when you click it, Bubble highlights the inputs that need attention.

This has actually been a major source of frustration for me in the past and is very poorly documented. I initially thought it was a bug when I first encountered it.

[georgecollier]

@boston85719

Just set input to should not be empty, then whatever workflow the button triggers, if it uses inputs value, the button will show as not clickable but when clicked, if any input is empty will set focus to that input

Works most of the time, except when required via nested custom events etc

[boston85719]

@georgecollier

Works most of the time, except when required via nested custom events etc

Meaning button triggers a series that triggers a custom event that triggers a custom event that is passing from one custom event to another a parameter value instead of the input value? If so, I suppose because nested event receives a parameter value and DB action in nested custom event uses parameter value as field value source and not the Inputs value.

So fix is nested custom event uses in the db action a reference to input value, not the parameter value.

[nocodeventure]

In production, we can’t really trust conditional statements from a client side element, it might break. It’s best to do this with a custom trigger as explained, because in that case you can also run more custom logic.

[code-escapee]

Anything triggered on the page runs client side, whether it’s a group conditional, a button WF / conditional, or a custom event. Putting it in a CE doesn’t make it more reliable.

[nocodeventure]

*conditional statemens from a client side element.

[ihsanzainal84]

Definitely a nuisance. I now make sure that I pass the input values to the/a custom event attached to the element clicked event, regardless of when I actually want to pull values from the input.

This workaround works well so far.

[boston85719]

@ihsanzainal84

This workaround works well so far

It is a cool approach that @ruiz86 shared as it uses the inputs value directly, so can be called via any nested custom event and work.

[ruiz86]

That giant conditional statement I showed in the example definitely wouldn’t be how I would do it. I only used it here to illustrate. Besides, sometimes we work on apps developed by other devs who don’t always organize things the way we’d like.

Anyway, that other approach you mentioned has always been my favorite in cases where I need more specific control over certain things; I use a yes/no group to validate and keep things more organized.