Airtable
Most of the documentation on Airtable exists in the Airtable base itself. If you go to the Airtable base, you should be able to hover over the base name to see documentation on the base.
Most of the table and column names have self-explaining names, but for potentially confusing cases we have included documentation. If you hover over the table/column name, you should also be able to see documentation for the table/column, where relevant.
To minimize duplication, the documentation there will not be duplicated here.
Breaking changes:
- DELETING OR RENAMING A TABLE. Deleting any table will cause the app to break, as the table depends on all tables in some capacity or another.
- CHANGING COLUMN TYPE can also cause the code to break, and one should look through how a particular column is used in the codebase before making such a change.
- DELETING COLUMNS, RENAMING COLUMNS OR CHANGING COLUMN TYPES, as all columns are used by the app at some point to access information, and changing column names, case etc. would break things.
- DELETING GRID VIEW. Currently, every table has a view called 'Grid View' that the app makes requests to. Deleting that View will break the app. Deleting and/or modifying other views are fine as of May 3, 2020
The repositories uses the toAirtableFormat / fromAirtableFormat to convert between table/column names in Airtable's format and table/column names in conventional camelCase. This is done implicitly (because airtable.js is a generated file), but if you look into airtable.js you will be able to see both these functions and their invocation in the different airtable.js CRUD calls.
These functions also do some other conversions (like converting Announcements to announcementIds for example), with the goal of making the naming more descriptive/explicit (in the above example, for instance, Announcements actually referred to an array of announcements, which might be confusing).
To see these conversions explicitly, you can see the mapping from table/column names to their camelCase counterparts in schema.js. This is also the file that toAirtableFormat and fromAirtableFormat perform the conversion based on.
What this means in development is you must refer to table and column names in conventional javascript camelCase and in the format specified in schema.js. There should be plenty of examples to reference in the codebase additionally. Referring to a table or column exactly as they are named in Airtable would not work.
Our project uses an Airtable Schema Generator to automatically generate:
- the schema of the tables
- code corresponding to CRUD calls to those tables
These are the functions we use for the rest of our project. See Airtable Schema Generator for more information about this.
An underutilized feature that we initially discussed was using Airtable Views, which are different (literally) views into the database. This could allow for the display of only a subset of the rows or columns, and API calls made to a particular view would only return data in that view.
This is something that could be potentially very useful for future use cases (e.g. querying for subscribers could just be a query on the Owners table with the 'Subscriber' View), and is something worth looking into.