To avoid real-time updates on your object, try loading the data into a custom state on page load. This way, you’re only using a ‘snapshot’ of the data, and it won’t refresh with database updates. You can set the custom state on page load or with a trigger and reference the custom state in your UI elements instead of the live database object.
If you update the dB entry … you are … updating the dB entry …
The idea behind the use of custom states is that you can use that data and further manipulate on-page … so that if you refresh the page you lose those states … in other words … you are just playing around with the values … until such time in which you decide to save it to the dB.
That works for basic types but not objects. Or I am completely missing it.
It seems to me that the “set state” puts a reference to the object into the custom state and does not duplicate the object.
Lists in custom state will not update in realtime, because that data is a result of an action and states only change through actions. Bubble objects in any state will still update because it is stored as a Bubble object and is realtime.
AFAIK you cannot make a Bubble object static. You’ll need to create a psuedo object using JSON then reference that JSON to store updates client side.
As a side note, every Bubble object that gets loaded into a page will add to the realtime WU cost each time there is an update. You can overcome this by retrieving data using an API call and returning data appropriately.
Building a JSON object client-side … awesome @ihsanzainal84 !
@bonjour_17 I was simply suggesting that instead of storing the entire object in a custom state … to store individual fields (e.g., text, number) as separate custom states. This would avoid updating the dB entry in real-time and you could manipulate the individual custom states directly to display them “dynamically-on-page” to the user.