Hi, was curious to see what the WeWeb recommended practice/what other folks have been doing for a couple of things:
Preventing Double Clicks on Buttons
Having issue with buttons and users double clicking, which wreaks havoc on my analytics and database if I forget to add a safeguard.
Until now I’ve just been adding a disabled state, but this is less ideal for building fast and also results in a lot of variables cluttering up the interface.
Ideally would love to just have a fast way to debounce on each button I create, without having to add too much to the button.
Was thinking of adding this programmatically (unless there is a faster no code way!), but then that leads to the next question:
What is the correct/recommended way to access “the current object” from its onClick or onMount handlers?
I’ve been playing around event.target related queries, but those don’t seem the most reliable, eg sometimes the parent div returned from event.target will be different.
Fetching the div by its id/class can work, but was wondering if there was an internal WeWeb way to access the current element that is kicking off the onClick?
Hey, you could do a component, so you build this once, and use it everywhere, it also makes it easier to iterate. You could do a “loading / processing” state, it should be simple with states and component variables.
No need to do this with code it should be event.target or something along those lines, try console.log(event) in the Custom JavaScript action.
@Broberto my dude many thanks! I had no idea there were component level variables - that makes life so much easier I had a feeling I was missing some of kind of smarter “WeWeb” best practice way of doing things
On the JS side of things, I’ll give event.target another try - I was playing around with grabbing the class of the parent of event.target but it seemed like this wasn’t that reliable, it was missing a lot of fires
Ahh thank you so much again!! Component variables have been working perfectly
I guess it’s no longer needed for this case, but will have to poke around and see if they do expose some kind of context from the onClick workflow. Unsure if this is not good practice to use this, but feels nice to have!
