Hi K, what you were seeing is dates that came from my API. They were not produced at that moment by the API call. They were dates STORED IN MY DATABASE. The dates came from a PREVIOUSLY EXECUTED API call. I was fetching the values DIRECTLY from the Calendar object being visualized on that page. I was NOT showing return values that came back JUST THEN by an API call. (See what I mean?)
Those dates were dates from the “Start” field of that Calendar’s “List of iCalfromURL Events” stored on the object. That list was populated by an API data call like this:
In the image above, iCalFromURL’s Event is the array of complex objects my API returns to represent iCalendar events. iCalFromURL’s DaysBlocked is the array of date objects my API returns to represent all individual booked days that are part of the Events.
For a little more detail, here’s the setup for the API call itself in Bubble (the dialog that pops up when you configure the parameters for the API call – my API takes a URL to the iCalendar .ics file in question as well as a time zone [so that the date math is done correctly]):
When this “Make changes to Calendar” step is complete, Calendar’s iCal Events is a list of those “weird” iCalFromURL Events and Calendar’s Booked Dates is a list of dates.
So what I was showing you is that YOU CAN fetch a list of complex objects from an API and store them directly in a field IN THE APP DATABASE.
Once the values are stored in that way, you can READ them back, as in my example, show them in a list. But apparently the only linkage between one’s app database and those objects is the field in which those objects are “stored”.
It’s EXACTLY THE SAME as if you had an API that, say, creates and returns a made up book title (let’s call it MakeASillyBookTitle). If you set that API up as a “DATA” type call, you might do something like:
- Create a New Made Up Book and, in that step, you set the value of a field called “Title” to be the result of the API call to the MakeASillyBookTitle API. The string returned by the API call gets pushed into the Title field of the newly created “Made Up Book” object, right?
This is how my iCalFromURL API is used. At either scheduled times, or as an initialization step in various places, I fire off a workflow like what you see above. Asynchronously, Bubble goes out, pings the API and brings back a fresh version of the events represented by the iCalendar at that URL.
The point being to insure that events I might be displaying in my app are as up-to-date as one can expect.
This all works swimmingly. The only downside, like I’ve been saying, is that the ways that one can USE those previously stored event things are limited because they are (apparently) in another table or something and are not actually “in” my app’s database in the same way that OTHER complex data types are.
Does that help you understand?