I have a question on how to use thing-like custom states. I have a group containing several input elements, and the goups’ custom state is by declaration a thing with fields receiving all these input values upon pressing a button. The workflow behind the button does NOT create a new thing, nor is any instance of a thing ever attributed to the custom state. Instead the workflow directly tries to change the custom state itself by means of “make changes to thing”.
All of this is well defined, no errors indicated. But upon pushing the button nothing happens, i.e. the custom state remains void as if it had never received the data it was assumed to be served by the workflow. Why? Is it really necessary to create a thing and attribute it to the custom state before the fields can be filled? The matter is, I don’t need a new thing, just want to store temporary information in the custom state using a certain data structure. The custom state can be deleted as soon as the figure closes.
Think I see where you’re stuck. The make changes to a think workflow is meant for changing things that currently exist in the database. Rather, what you want to use is the “Element Actions” > “Set State” workflow.
I made this video a while back that may provide some guidance…
With a custom state, it’s good to think of it like putting a bookmark inside of a book. It’s incredibly helpful once it’s placed on a page. But it’s not actually altering the book (nothing is created). And, as soon as you remove the bookmark and close the book (ie. refresh the page), the bookmark has lost contextual value.
thank you so much for your kind answer and the cool video!
Here the problem with the “Set State” function: if the custom state is a temporary thing, one would want to access and fill its individual fields, one after the other. But this is not possible with “Set State” as it calls for the handle to the entire structure (or its “root”), not its sub-fields. “Set State” requires a value to be passed for the root, but what if there is nothing to be passed since the root neither exists yet nor is of any practical interest? For simple custom states like numbers or yes/no variables bubble allows the user to skip the definition of the root, but not for composite things.
In other words: the book to be bookmarked by the custom state has yet to be written into this very same custom state, so this seems to be a hen-egg-problem . What is the best way to work around this issue?
yes, this works of course, but once your app becomes vast, you need to hold in check the number of objects as well as the forest of names, so the writing and searching efforts are limited. The only way as I see it is to use things with fields, as their name structure is unique and once and forever fixed.
Example:
Use a thing with 8 sublevels of which every one has 6 fields. Good luck defining the 48 custom states by hand And this was still a rather innocent case, in reality effort grows exponentially with every new level added. At a certain point it is a K.O. for manually entered custom states.
here one compact example (sorry for the labels in German). In the following group the users can define 8 text snipplets by working through the radio buttons on the left. Every of the 8 snipplets carries a multiline text as well as 5 formatting informations. All of this is stored once the button is pushed. So there is a total of 8x6 = 48 fields to be defined and stored in the enclosing groups custom state:
Right now I have a data structure (thing) for the 6 data fields defining one text snipplet. Dealing with 8 such thing-like custom states would be already much less cumbersome than dealing with 48 hand-written custom variables.
In this case, it is much better to create a temporary thing in the database that serves as a container for all of the inputted values.
I really recommend not using custom states to handle anything where the user is creating lots of data that could be lost by an unintended page refresh or a spotty connection resulting in needing to re-submit.
Let’s assume this object is a popup. When the popup is opened for the first time, you create a new object in the database. All of the inputs are empty, except for a field called is_draft, which has a boolean value of “yes”. (If resuming, don’t create a new object. Just display the relevant record in the popup).
As the user completes actions within this popup, they update the data of the actual object in the database (using either auto binding or a submit button for each tab). Then, once they hit the final “Submit” button, change the flag from “yes” to “no”.
Wow, didn’t think at all about the risk of losing data due to page refresh, thank you! So you say custom states may be a bit risky in situations where the user’s interaction with the GUI takes too long, or the internet connection is unstable?
And concerning the database entry for draft-purposes: I guess having already only one such draft thing may not work too well if several users try to access the same object at the same time. So there needs to be a draft thing for every user. I remember having tried this once, but re-finding this thing by it’s unique ID didn’t succeed. If such a thing is created only for the use within a session, how do we destroy it automatically at app closure? Storing the things ID in the thing itself, and then writing an exit function for the thing to self-destruct? Because we certainly want to avoid the out-of-control accumulation of these drafts in the database, right ?
Thank you so much for your help, your experience helps me avoid very far-reaching errors !
Bubble works fairly well for updating data in real time, so I wouldn’t worry about that too much. When two users are trying to update something at the same time, it’s helpful to give some sort of visual cues. (And I be wary of using auto binding if multiple users may be editing the same thing at the same time).
For deletion, if we continue with the idea of using this form within a popup, you can have a “When this popup is closed” workflow run. Set a conditional state to “delete” the thing when the Popup is closed and is_draft = yes.
I do believe too it’d be beneficial to have temporary things.
The use of Things in tables with a draft flag is a little bit messy in my opinion. Also it could lead to inconsistencies such as:
A Thing is created and saved, thus draft flag is false.
The user starts working updating the Thing through a form, but for whatever reason (say internet connection drops), the user does not close the form or cancels the edit, therefore the Thing remains in draft state. Say that the app only lists Things which are not in draft. That particular instance would not be listed, even though the user would probably wanted it listed in its previous mode.
This could be solved by using temporary tables (and cleaning them up periodically), so the final data would be copied to the real tables once the user submits the changes. But given how expensive it is currently in Bubble to create and update things in DB, this is not only messy but performance consuming. However, with temporary Things I believe (I could be wrong) this would be much more straightforward and quick.
. What is the best way to work around this issue?
And this was still a rather innocent case, in reality effort grows exponentially with every new level added. At a certain point it is a K.O. for manually entered custom states.
?
for this great advice !