One More Discovery About Custom States Power

Case:
Three buttons. OnIt, UpVote, DownVote.
OnIt button gives the priviledge to the user to access the voting section as only a limited number of votes is possible on a post (question).

So the problem I encountered that a user can click on 2 OnIt buttons (especially on the mobile screen) before the database has enough time to register OnIt = Yes. Hence it was necessary to use a cilent side CustomState that can immediately register a value of OnIt_State=Yes so that it’s nearly impossible for a user to click on 2 on_it buttons. Which really worked!

Another question… why didn’t I use ONLY custom state here? Simply because, if the user closes the browser there is no way to know the last CustomState, AND it is necessary for me to be able to permanently block voting ability, so a database field is necessary anyway.

I am presenting you this case here, as I wasted too much time figuring it out. I hope you don’t hesitate to use both custom_state and field variables to secure an intensive button based application like the one I am doing.

You can achieve more or less the same by pre-loading the thing in the group linked to the voting buttons and then making a change to the parent thing based on vote the button.

I am not sure I understand you. What type of thing? DB Field or Custom State?

Sorry. Didn’t take into account the mobile tapping problem. Let me check later at home and see if what I said is actually valid to avoid quick mobile tapping.

1 Like