Is there a sample code snippet to pass table records into a function? Do I also need to pass the table or field itself (because I need the field to get cell value, or the table to get the field, right?)
How do I call datetime_diff from a scripting block?
Is there a function to raise a float to an arbitrary number?
e.g., 2^1.04 = 2.0566
All of the SDK that Airtable makes available is documented in the Scripting block. Mostly all you are using the SDK for is to retrieve records, retrieve information about your base schema, or update/create/delete records.
I haven’t been able to find any documentation on the scripting block - is there a link?
What is the right way of selecting the first record?
let date0 = query.records.getCellValue(date);
Lots of basic questions - the scripting block documentation just has 5 pretty limited examples
let date0 = query.records.getCellValue(date);
The documentation for the Scripting Block is located in the Block itself, underneath where you write your code:
The documentation is pretty thin, but that’s because the API is pretty thin also. Airtable is only concerned with providing you access to your tables, views, and records via the API, and access to create, update, or destroy them.
Since you are working with dates, you might benefit from taking a look at my Example Script for Detecting Scheduling Conflicts:
It looks like you are mostly on the right track with stuff, and I promise you that you will learn far more from the difficult “troubleshoot as you go process” you are going through now than you would by reading documentation! Experience is the best teacher.
Another little tip - make use of the
output.inspect() function Airtable makes available while you are trying to figure stuff out. If you are unsure what some variable in your code might be holding at any point, throw it into an
output.inspect(variable) and run your script to see what it is, what shape it takes, how/if it can be delved into, etc.
@Jeremy_Oglesby, great post.
… and excellent insight. And by “thin” I think you mean good (mostly). The SDK Airtable has created is concise, relatively simple to learn, and extremely powerful.
Early on I had trepidation concerning the lack of filter queries and things that are undeniably critical in API integration, but then I realized two things which are key distinctive qualities about Script Blocks -
Gathering records from a table does not actually embody the fields themselves [see output.inspect() of any recordset and you’ll see just how lightweight this request is].
The underlying architecture of Script Blocks appears to lean on the existing Airtable UI [i.e., a block runs in context with the UI and as such, all the data has been previously requested].
Thanks, the example is very helpful.
It is there, @ATG – it’s in the “Cell values & field options” section, which is linked to from the
Can I chime in with my thoughts on the Scripting Block documentation?
I think that the information in the Scripting API documentation is excellent.
- It contains a wealth of very detailed information.
- Being able to easily copy code examples is awesome.
- The examples are generously scattered throughout the documentation.
- In several places, the documentation has links to outside reference material.
- Some of the examples pull in actual names from the current base.
- The formatting is (mostly) beautiful.
However, the documentation does leave several things to be desired.
The documentation window is tiny. This discourages people from using it. It is also very hard to see the documentation, a significant portion of code, and actual records all at the same time. When trying to put everything together, it would be nice to be able to comfortable see them all at the same time.
Navigation within a section of the documentation is poorly supported. If you want to know what is covered in a section, you have to manually scrolling until you get to the info you want.
Then, there are a few minor quirks:
The documentation does not cover some items that I think should be covered, because they are unique to Scripting block. (I’ve run into this twice.)
The Scripting block does not always follow documented behavior. (I’ve run into this multiple times.)
The Scripting block editor sometimes is overly enthusiastic in flagging possible errors.
There are undocumented features. (I’ve run into one.)
I second this - some of the information I was looking for was there but took too much scrolling to find.
Would be much easier to pick up with a quick primer like this
Indeed, I agree that we need better examples. but keep in mind that this new feature was created a few months ago and release from beta under great pressure from the community. It’s bound to have significant documentation gaps.
Often, we want these new features in the worst way, but we’re also annoyed when we get them in the worst condition.
True, except…one is free, and the other isn’t.
Hmmm… does that really matter? They both have free tiers; they both have paid tiers.