I’m using the API connector to make a GET request. I then display the json data in a repeating group. Each repeating group element has an image and a few tags such as ‘liked’, ‘archived’, etc. Currently the only way I’ve found to allow these buttons to be ‘clickable’ is to trigger a patch request on click then refresh the page to show the updated tag state (yes/no). However, this isnt ideal in terms of user experience as it rerenders the whole page and calls the request on the entire data set.
Ideally, I’d like to store the data from the get request in some sort of state. Then when the user clicks the like button, I can trigger a workflow which toggles the state, then executes a patch request in the background via the API connector.
Any ideas on how I can save the response json data (list of objects) into a custom state?
If I understand your question correctly, you can create a workflow On Page Load and in it, you can set a custom state to the page and reuse this custom state in more places.
That makes sense (for some reason I thought I’d have to grab each list item from the fetch request and attach it to a separate state).
I’ve got the images rendering on the page, however I’m struggling with the toggle functionality. I’ve created an ‘isLiked?’ custom state, and I’d like to attach a dynamic default value to it (which would be the value returned as part of the initial get request).
Any ideas if this is possible in bubble? (Or alternative approaches)
You can get the whole request result into the custom state of the page. If this field (isLiked) somehow found in this custom state, you don’t need another one. You can just refer this custom state in the conditional tab here. Simply, you don’t need another custom state.
Does that mean it would be possible to update the value of a single field in the custom state? i’m attempting it but the workflow only gives me the option to update the entire state (not a single value)
This is the list of objects that I’m saving to the custom state, but I only want to update the liked field on the UI (the update on the backend will be done via a sepate step in the workflow to avoid having to rerender/refresh)
You probably have to update it as a whole. But technically, updates shouldn’t work like this as far as I can see. I guess you want to post the data back when something is liked (therefore, update it in the custom state as well). IF this is the case, I think if something has changed on the page (someone liked something), I would update it in the server (if you are doing api calls, probably another api call), then get the final data to the custom state again. I don’t know if that makes sense?
You might have to think more about how this process will work. The page is loaded with whatever in the API. Then, if something changes in the page, you update the things in the server and get the latest data again.
Yeah that approach seems more achievable from a Bubble perspective.
I was trying to implement optimistic updates to provide a smoother user experience, but I’m only able to get it to work if I have the fetch request data replicated in the bubble database (as it becomes easier to reference that way).
Your suggested implementation seems to be alot more feasible so I’ll give that a go.
