UI Updates vs DB Updates

I have a number of buttons on my site whose states are connected to database values in the back end. When a button is pushed, it updates the database, and the states of the other buttons are reflective of the new DB value.

I’ve used “when button x is pushed” conditional statements to keep the UI snappy, which works as expected. However, when the button is released there’s a delay in updating the DB, so the states of all the buttons revert back to their initial state then update to what they should be.

If I remove the “button is pushed” conditions, the UI is slow to update (as it needs the DB to update first), so I’m either stuck with what looks like a slow UI or a glitchy UI.

I’ve tried setting temporary overrides (e.g. with element states or displaying data in a parent group) before doing the DB updates (either in a front end or back end workflow), but nothing I do seems to fix the issue.

Hoping anyone might have some ideas how I could fix this one.

Can you give some more context on what is then happening to the buttons with these states? to help think about some workarounds.

It’s a bit tricky to describe, but I’ll give it a go…

I’ve set up some pseudo-sliders, which are stacked buttons, with some hover states, etc. to work like a slider but look how I need.

So, essentially clicking on a button just updates the database with the value and the other buttons stacked on top or behind go invisible, leaving the one that’s clicked.

You can see in the attached video, I’ll make some selections, which revert to their original state before the DB updates and information is sent back to the UI.

I hope that helps explain it a little better.

1 Like

Okay cool,

So one option (which is lame) is to just hold these vales as variables and then only update the db when they click save at the bottom of the form. Which can be good from a UX standpoint in some aspects, but I do like the idea of updating them on the fly.

I would take the approach of custom state or displaying the value, obviously exactly how thats set up is based on if you’re using option sets etc, but you mentioned you’ve tried some workarounds but it hasnt helped?

I would think that as long as youre swapping from displaying the DB value, and instead displaying your current value, there should be no lag between the two.

For example if i put a group in a hidden popup, called it Var - business services Q1 and made its type number, left it blank, then put a conditional rule that if this was blank the data source would be pulling from the DB. Then when the user clicks a button i would display the number in that field and also kick off the WF to change the DB value. That shouldnt give any glitches I believe?

Slight caveat is that if for some reason that WF fails (super unlikely) then the user may believe the field is populated with one number but in fact it isnt, but I dont think thats a big issue in this case.

Sorry for the essay!

I’d say thank you for the detailed response!

I’ve actually tried what you’ve suggested with the wrapper storing a variable which is referred to (rather than the DB value) when the button is clicked (i.e. step 1). If the variable is empty, the DB value is used:

Still, for whatever reason, there seems to be enough of a delay in storing the variable that I still have the same issue.

I’ve tried adding a delay between steps 1 and 2 as well as moving steps 2 and 3 to a backend WF to keep the front end snappy, but still seem to run into the same problem.

Of course, the problem might be related to the dev environment being a little slow at times…

I’m going to build a test sandbox for this in a bit and play with it out of curiosity because thats confusing!! Will come back to you

1 Like