I want to make changes to individual fields inside of a custom state, which is of type Example (for example ). I tried to Make Changes to a Thing, and select the custom state as the thing. But alas, no changes were made. Should I assume then, that Make Changes to a Thing only works on DB objects and not custom states?
@keith maybe this is a job for Floppy (a plugin Iāve heard about, but havenāt yet fully explored?)
p.s. If helpful, the reason Iām trying to do this is because I have data coming in via API thatās the same schema as my Example data type. However, Bubble doesnāt see them as equivalent. Make Changes to a Thing was my attempt to assign the values of the API call to the custom state.
Thanks @boston85719 In my case, the API call is actually a mock API endpoint courtesy of the JSON Assistant plugin. So Iām not able to ājustā set the custom state of Type A, when the mock API endpoint is of Type B. I guess Iāll just break out the Type A data type into its constituent fields, and assign the values that wayā¦
Not what I would doā¦I would just use the plugin for all of what it is worth, which in this case is to use it to store the JSON and modify the JSON instead of bothering with custom states at all.
@boston85719 For posterityās sake, Toolbox offers a good way to āconvertā from one data type to another. Specifically, the Javascript 2 Bubble element ā Run Javascript action sends the unique ID(s) to the JS2B element, and JS2B publishes as the desired data type. As a singular item or a list.
Yes, this is similar to how that works for URL parameters as well. It is a single item search using the unique id that takes place in the background. It is also how a Do a Search with constraint of unique id = (unique ID value), so there is no real reason to use the toolbox plugin to send the unique ID via javascript and have the javascript to bubble element āconvertā it to the actual DB entry unless you are needing to send the value from a reusable element to a page or another reusable element.
What about latency? Meaning, with Toolbox I could run JavaScript and āconvertā asynchronously without blocking the UI thread. Meanwhile, āDo a Searchā would block the UI thread, and create real and/or perceived latency. No?
There is no difference. Toolbox doesnāt magically convert to the thing. It performs a do a search with constraint of unique ID, the same way as do a search. Both need to request from server for the database entry.
Yup, get that. Based on my testing, however, Do a Search for unique ID blocks the UI thread, while aysnc Toolbox Run Javascript does not. (Specifically, Run JavaScript async ā J2SB ā publish value.) Even though both, as you point out, need to make a server call for the DB entry. Anywayā¦ appreciate the conversation as always.
Okay, I think I understand what you are sayingā¦basically if you use the do a search for thing, the user is not able to proceed until the search is complete, while the javascript approach doesnāt cause the user to need to wait for the search to complete in order to continue using the app.
Huh? What ālatencyā does a single search to a state vs a plugin search have? A call to a J2B element still runs code in itās own instance. Thereās no voodoo going on.
). I tried to Make Changes to a Thing, and select the custom state as the thing. But alas, no changes were made. Should I assume then, that Make Changes to a Thing only works on DB objects and not custom states?