Hi all, I am having an issue working with the API Connector and repeating groups.
I am using a repeating group to display data that is returned by a GET call to my server.
In order for the API response to be valid as a datasource for the group, the API call must be marked “Use as Data.”
I have a workflow set up in my application where a user hits an icon in the same repeating group, this icon kicks a workflow which 1. sends a request to remove the item from the list and then 2. triggers a GET call to retrieve the new list and update the repeating group dynamically
My issue is that I do not know how to trigger this GET call without having the API call marked “Use as Action”. If I mark the API call as “Use as Action”, then it is no longer a valid data source for the repeating group.
A workaround that I thought of was separating Data from Action in my API definition. So I defined a GET Data and a GET Action call that are identical except for the “Use as” field. This workaround hit a wall when I realized that Bubble treats the data returned from these calls as two separate object types, and that when I trigger the GET Action from my workflow, it has no effect on the data that the repeating group receives from the GET Data datasource.
TLDR:
How can I trigger an API call marked “Use as Data” from within a workflow?
Please educate me as to the ideal workflow for integrating repeating groups with external APIs.
Unfortunately, this thread offers 2 options which each have their own issues:
Option 1 is to create a custom state and set the Repeating Group to display this custom state. However, when my custom state pulls data from my API call to update, it appears to be using the cached data still.
Option 2 is to add a Date to the header request so that bubble reloads it every second. This will be too high bandwidth as we are experimenting with replacing our existing client-facing application with Bubble at the moment.
Option 2 Can work only when you need. You will trigger the display list with the current date after the action of creating or deleting an option, not every second. The bandwith use will be the same.
If the first option doesn’t work, you can also send a support ticket to ask Bubble to have a look. And just to make pressure for bubble to make Display list work with Data API like everyone expect! More we will post this kind of request and more chance we have to see this fixed I think.
@Jici Thanks for pushing back on my incorrect assumption! Turns out my datasource request included the data header, but I left it out in my workflow request which is why the data was not updating!
