Hi, there! I have a RG and would like to combine two datatypes: API data call and other type of content from database. Is there a way to play around and place both data types in one RG? Many thanks!
Maybe there is a way to transform API data call into data type stored on data base saving it on temporary memory?
The answer is “sort of”. Your API call returns a list of things? Are the things returned simple? Or are they a complex object (multiple fields/keys)?
Yes, this API call returns a list of articles with nine fields: Title, Description, Author…
And then your other data type is probably a similar structure, but coming from your Bubble database, I’m guessing?
exactly! it has same structure containing some extra fields
This is what I’m talking about when I refer to the “API Ghetto”. This needs to get fixed. I’m going to submit a formal bug report on this today. There’s no sensible reason I can see that we need to do these kinds of shenanigans (parallel data types).
When that list comes over from the API, the individual item elements in the list need to be assigned a database data type by Bubble. (This does not happen at present.)
I am supporting your initiative!
Anyway, the idea on combining the lists:
You could “sort of” do this if the things contain some sort of unique identifier. For example, perhaps your API List of Books has a field for ISBN or something that will be unique. Your Bubble DB List of Books does have unique IDs (the Book’s Unique ID).
If your ISBN or similar field is a text, you could merge a list of ISBNs and a list of unique IDs as both are of the same type (text). Consider:
API List of Books’s ISBN <-- this is a list of type text
Bubble DB List of Books’s unique ID <-- this is a list of type text
API List of Books’s ISBN:merged with Bubble DB List of Books’s unique ID <-- would be the merged list
You could make that merged list the source for a repeating group (that group is going to be of type text). Fields within the cell could then do a lookup to tie the unique text back to the original item.
You can now put two groups in the cell. One group will have a type that is your API Book thing. The other will have a type that is your Bubble DB Book object. The data source for each would be like:
API List of Books:filtered:first item where the :filter operation is Advanced and the expression is something like: This API Book’s ISBN is Current cell’s text. Get it? This will return a list with 1 item in it – the API Book associated with the ISBN in the current cell. You could then format text objects inside that group to display info on the book in question. If that list is empty, this cell represents a Bubble Book, not an API book and you could hide the group based on that condition.
Similarly, your second group’s data source is something like:
DB List of Books:filtered:first item where the :filter operation is Advanced and the expression is something like: This Book’s unique id is Current cell’s text. This will return a 1 item list with the Bubble Book object associated with the unique id text in the current cell. Again, you format some text items inside the group to display the book info. If that “list” is empty, this cell represents an API Book, not a Bubble Book. (And you could hide the group based on that.)
This is a whole bunch of nonsense, of course, but it can be made to work.
(I actually do something exactly analogous in my own app: I have calendar type events that come from an API. I have a parallel data type representing events in my own database. To display both types of things on a calendar (built out of a repeating group), I do these kinds of filtering operations.
This is of course slow-ish and all (or at least a lot) of the compute is done on the client side. (:filter operations are done in the browser) As I’m sure you’re aware already since you’re running into this issue, you cannot “Do a search for… API Books” as that is not a data type that exists in your database, even if you store the returned value list in your database.
(This is an infuriating problem.)
Thanks, @keith! Wow, there is a fair amount of ingenuity in your solution for this issue! I just need to be aware of loading speeds, but it definitely will work in my case.
One additional tip that can make this easier to reference the items in question and makes this all more performant:
Suppose these two lists of disparate objects are (1) the result of an API call (that seems to be the case for you) and (2) the result of a “Do a search for… Books”
When you do those operations, store the results in two different custom states. You can put those states anywhere on any element in the page, but a natural place would be either the page object or the RG where you’re displaying the joined results.
Use the element inspector (click the “i” button on an element – the one shown below is a page element) to create your two lists. In my case, it’s like this:
Imagine in your case these would be like “Bubble Books” and “API Books”.
Now for example, you might have a search input and the user is gonna search for books with “Dogs” in the title or something. When they click some button, you go out to your API and get a list of dog books. And you also go and “Do a search for…” dog books in your local database, right?
Store the results of those searches in these two custom states. So you’ll have a workflow that’s like:
When Search Button is clicked:
- Element > Set state > blank’s Bubble Books = Do a search for (whatever criteria)
- Element > Set state > blank’s API Books = Get data from an API (whatever criteria)
Now you can more easily reference these lists. The source for your RG would be:
blank’s Bubble Books’s unique id:merged with blank’s API Book’s ISBN
Great tip! Using custom states will definitely help to source the data smoother.
Thanks! this was exactly what I needed… also another note that may help someone… IDs are higher the later the are created so you can sort a combined list like this as text (id numbers) and it will be in date/time order! BONUS