Forum Academy Marketplace Showcase Pricing Features

Ideas for a better way to do button disabling/enabling?

[beginner here]
Before Bubble, I’m used to just calling a function to set the disable state of a button…and I expected to find a "disable/enable’ thing in a workflow action (not just Hide/Show). I did find something that works great, but figure I’m probably doing it the Hard or Ridiculous Way. Any input or tips or corrections welcome!

My Typical Scenario: User hits a ‘submit’ button and I want to immediately disable (not hide) the button until after I’ve finished doing something with their info.

Custom state change in the workflow was my answerwhen combined with the thing-I-keep-forgetting: the “conditional” tab on the element. And of course I kept looking for “disabled” but in Bubble-speak the thing I want is called “not clickable”, and works perfectly.

A little trickier… sometimes I want to disable the button for few seconds – a literal timing pause – before they can click, NOT based on something else happening. Here’s what I did:

  1. User hits the button and the workflow sets the custom state that the button ‘conditional’ is listening for. Button is now disabled (“Not clickable”). But I want it to come back on in a few seconds, so…

  2. Next item in the workflow is a “Schedule custom event” with a delay of 3 seconds.

  3. Created a custom event (the one triggered in my workflow after I disable the button) that then changes the custom state for the button back to “enabled”, and the button element’s conditional ‘hears’ the state change.

This all works great, I just want to know if that process makes sense: using a custom state changed and a ‘schedule custom event’.

Overall, I’m super impressed how much you CAN do in Bubble. It is starting to feel less restrictive now, and I have only barely scratched the surface and am making approximately 347 mistakes per hour.
Cheers, Bubblers.

Yes, you’re essentially doing it the right way except for #2. There’s no need to have an arbitrary delay. Just listen for the event that means the wait is over.

:+1: this is the way to go.

:joy: everyone.

1 Like

Yes, thank-you! The second one is for times when I deliberately want to insert a pause into the user’s experience… where the app itself is ‘ready’ to accept input, but I just don’t want them to (e.g. I want to literally add friction so they can’t just mindlessly step through the questions, etc.).
But most of the time, it’s based on the button click being inappropriate at that time, and for that I know I’ll need to learn a lot more about how to determine when, exactly, the activity in the workflow was actually completed. I still don’t know enough to know what questions to ask on that part…

I have faced this problem often myself. And I find the current solution quite cumbersome.

I have submitted an idea on ideaboard to have this improved.

Hope I have captured it correctly.