If you are loading all the records in a table and then enumerating them only to build yet another array representing the same records, I must ask why? Why not simply return
records? It is an array with all of the data - even the data that is in nested objects such as fields of type
At the outset, there’s nothing wrong with the Airtable SDK, but because it attempts to [quietly] overcome shortfalls in the API (such as true queries), I tend to develop 100% of the code required to extract Airtable data. Color me “old-school” in this example.
For this guide, I’ll use the Airborne Search Configuration table because it contains one record with an attachment which is a 1mb ElasticSearch index document which is a full-text index of many other bases. The field
IndexRef is a field of type
attachment and I know that extracting values from these field types if your key challenge. Here’s what the table looks like.
As a simple starting point, consider the following function - it returns only the first page of a table (just 100 records). Passing the
to this function returns the records as JSON text.
While the response is JSON, it is not parsed
. More on that later.
Now, take a close look at this simple example that uses the API function call to get 100 records and enumerate them.
It will return a collection of records like this one:
What’s happening in the enumRecords function?
- Line 38 retrieves a list of records in JSON format (as text).
- Line 43 parses the JSON
results text into an array of records. Note -
.records is added outside the parsing function because we really only want the records node which is not accessible until we first parse the
- The enumeration of the records filters for a record where
IndexRef is not
undefined (see line 52).
- At line 56 we log the stringified version of the record so we can easily examine it in a JSON parser (if we want).
- Finally, line 59 logs the attachment
And the log output looks something like this:
Note how this example doesn’t have to build a new array consisting of the data to get at the attachment data. In fact, the promise of JSON is that – aside from the parsing step – it is readily consumable as soon as your app has it.
Also note the direct access to all the fields in the attachment collection; accessing this data should be no different than accessing any other data. I suspect the SDK does this for you, but it seems that its integrated helper methods is what may be confusing you. I’m also certain that using the SDK, you can build a better version of my training code and likely with fewer lines. I don’t use the SDK so I don’t have any demo code to share with you.
Lastly, as I’m sure someone will type in the attachment URL to snoop on it, I’ll save you the trouble. It’s a Lucene-inspired full text index of the demo bases in Airtable and it is fully accessible without credentials because all Airtable attachment URLs are open and accessible to everyone. Ergo, be very careful when you expose attachment URLs in any context - they are public documents.