So I currently have series of toggles that look like this
When the user clicks any one of the circles, the workflow runs a simple action to add that social account to the current user’s social accounts. This “social accounts” field on the user table is just a list of texts. In the above example, the user would have facebook,linkedin,twitter as the valueof their social accounts.
As mentioned, these are toggles so if you click one of them off (e.g. click facebook when it’s already checked), then that text value is removed from the current user’s list of social accounts.
This works fine except for when you try to toggle them on or off too quickly as bubble does not queue the requests, instead they just try to modify the user record all at once which can cause issues. Even if they did queue the requests, there is still a delay compared to handling this completely on the front end (i.e. with a custom state or local storage) which makes for a less than ideal customer experience as toggles states are best stored in the front end.
The reason I can’t just handle this all client side is because I need this value to persist across devices, which clearly has to be handled via the db.
So my question is this:
What is the best way to update the db asynchronously? One option I have come up with is to have the circular toggles directly tied to local storage or a custom state and then any time a user clicks on one of the circles, it runs two actions in the workflow:
- Set state (to add or remove the value from the list)
- Make an api call to a backend workflow that updates the user record with the checkbox “attempt to make the call from the browser”:
That theoretically solves the server side action delay experienced on the front end but comes with two issues:
- I remember reading somewhere that this checkbox only does what it says which is “attempt” to make the call. If it can’t then it will run it server side. Additionally I don’t know what would cause it to fail making the call client side and have to revert to server side (maybe it’s only when a CORS issue arises?).
- This still doesn’t queue the requests. If two of these backend wf api calls try to modify the user record in too close proximity to one another then the custom state/local storage on the front end could get out of sync with the back end.
The other option is to run the action to update the user record in some workflow that is associated with the user seeing a loading gif elsewhere in my app (i.e. add it to a workflow that already causes the user to have to wait), but the issue with this is that the user may close out of the app before they get to this loading gif section and then the custom state/local storage is now out of sync with the user record.
So long story short, I know I could build out some sort of queuing system but this seems overly complicated or I could just hope the user doesn’t notice the out of sync issue I described in the second option but that’s not ideal either. Either way, I’m wondering if anyone has any better idea of how to solve this.
I’m really hoping there is a super obvious solution that I’m stupidly overlooking.
Thanks in advance