Basically temporary Things on page being able to be saved to the database at a later time.
Use-cases like Shopping Carts, temporary lists of Things on page that are too complex for custom state lists.
Right now we cannot make temporary Things on page for shopping cart-like cases. Custom states can contain Things but they have to be in the database already.
–
Some existing actions would get some new features like:
Create a thing - Now has a yes/no field for “Save to database” - defaulting to yes to mirror current behavior
Make changes to a thing - Now has a yes/no field for “Save to database” - making this yes would take un-saved Things and add them to the database after the fact.
It can be nested further, so an unsaved Thing could contain a child unsaved Thing, but if you save the parent Thing it saves the Child things.
This terminology already exists in Bubble, where if you try to set a datatype field with a text value, it throws the error “Must be something saveable” in this case all Things are saveable, but they don’t necessarily have to saved YET like they are now.
This concept already exists with Plugin Datatypes where we have some result from an API call that we can display on page as Things that don’t exist yet.
Exactly. However, we’ve been asking this for years… and it hasn’t happened. Definitely a power user feature with limited cases… so I don’t expect it anytime soon.
Power users are the ones who end up supporting the community with plug-ins, guides, documents, consulting, etc. We’re also the ones who make the more interesting things
It’s important that power users can … be powerful, I guess
Not sure if you’ve seen those plugins where they tell you pick a certain datatype from dropdown.
He’s just saying specifically a plugin for creating those objects via plugin element then doing something with them after.
It is a datatype from an API call inside the app, but instead of actually making an API call the code maps whatever fields to the datatype and stores/outputs it