I have a button on my page that checks for a true/false condition and accordingly updates or deletes a database record.
I’m a bit worried that this workflow might fire twice, for example in case the user very rapidly clicks twice on the aforementioned button.
Is there a way in Weweb to prevent this? For example by blocking further clicks on an element as soon as it gets a first click?
You could always create a variable that is binded to the disable setting of the button. At the start of the workflow, change that variable so the button is disabled, then re-enable the button when the backend process is done.
You could even add a wait time action to extend for a moment.
Could get fancy and have the text of the button change to a checkmark or something to signify it was successful.
That’s what I do currently (by hiding the button in the workflow once it’s clicked), but my question is what if a user manages to quickly click it twice (that is the second click would fire the workflow a second time before the first workflow even had the time to hide the button)?
This circumstance requires the user to click quickly enough that it the workflow “ducks in” between chained promises, while not so fast that the browser registers it as a double-click event. That’s a very narrow window.
I’ve been around this block a few times. I haven’t seen it happen in ww, but I have seen this situation happen in super-edge circumstances on web sites. I think of one in particular that had this problem because it was so video-and-animation heavy the event listener was triggering more slowly and irregularly, allowing this problem to happen more often.
When it turns out to be a real challenge, you can implement a solution like a debounce pattern to solve. A debounce basically means “don’t do it now, do it in 500ms”. Then a second click resets the timer. That way fast reactions are just put into the same queue. It’s quite effective.
But I wouldn’t go looking for tomorrow’s trouble when today has plenty. If this is a hypothetical problem at the moment, know there is a solution and move forward to see if it arises. In most circumstances it will not, and I would not recommend over-engineering for these high z-score cases.