Happy new year!
Modulartable is a project I’ve been working on since the second half of 2020; originally inspired by chatter on these very boards (e.g. Blockchaining) and wanting to do my very own JavaScript pilgrimage of reinventing the wheel just one more time because I’m sure mine will be rounder. The goal being native and systemic support for Airtable script modularization.
Background
I really liked the Scripting App since its beta Block days. Not least because the environment is much faster than even most paid coding repositories (I’ve tried them all while moving apartments this year, some are downright terrible. But the fact that it’s joined with a modern relational database opens up some wonderful possibilities.
All in all, I wanted to do more. But what little I did know of frontend got rounder and wheelier about a dozen times since I last took a jab at it. That’s how I started researching ways in which to emulate — and, eventually, implement — full-featured Airtable modularity centered around the Scripting app.
Today, I’m starting to open-source my findings via Airtable Universe and Gumroad.
While I’m far from done experimenting with various approaches, feature creep and an unlucky health streak (pro tip: don’t catch covid) inhibited my progress since summer. So I’d like to get some feedback and gauge interest in the project, before deciding which parts of it are worth pursuing, if any. Plus, this should make for a decent portfolio piece if I ever dare attempt a career switch to software.
This is a lite version of the repo containing proof-of-concept examples of the main stuff:
Controlled script imports
Controlled in the sense we can cherry-pick built-in objects (base, session, output, etc.) we expose to the code we’re importing.
This is an improvement over eval whose dynamic scoping is a security concern and a nightmare to debug the more complicated your system gets (most often due to clashing variable references).
Testing modules through the Scripting app
Adds convenience and encourages good coding habits.
Module caching
The main application revolves around using table/field descriptions for caching module references and module settings. Since the recent update allowing us to query specific modules, we can use this system to modularize code beyond the 50,000-character limit imposed within the actual Scripting App instance with a negligible performance impact.
As for caching module settings, that behavior is combined with input.buttonAsync as an example of an input.config alternative that supports default values/doesn’t require the user to fiddle with settings prior to running your script. Consequently expanding the UX potential / accessibility of scripts.
All of the code and documentation found in this base are open-sourced under the standard MIT License attached to each individual module.
This is the main project repository, distributed via Gumroad. The vast majority of the scripts and other content is available at pay-what-you want pricing, licensed with few limitations (it’s mostly the MIT license that applies).
The code and documentation provided herein cover not just the currently recommended approach from the Airtable Universe base, but also seven other techniques for modularizing code between Airtables (are we saying Airtables?) and Scripting app instances or automation environments:
- eval
- Function constructor
- async function prototyping
- function.prototype.bind/call/apply invocation
- ES6 import/export syntax (with support for dynamic imports)
- JSON.parse
- with
While there’s a lot of functional overlap, keep in mind that I don’t advocate for all of the above to be used interchangeably. Some of the documented techniques like eval and with shouldn’t be used at all outside of learning exercises and niche applications using normalized data due to security and performance concerns, both of which impact scalability.
As for what *should* be used in most cases (click for details)…
My currently recommended, largely universal approach for modularizing your Airtable scripts is a combination of one of function.prototype.bind/call/apply methods (pure preference) and either the built-in Function constructor (for regular, synchronous code) or a custom function constructor created by cloning the async function prototype (for asynchronous code). For a basic example, refer to the Airtable Universe base. For more advanced prototypes, check out the Gumroad repository.
This essentially allows you to mimick the desirable parts of eval without ceding control of your scope (which eval would modify on the fly) while importing Airtable-stored code.
Of course, remember that the first step to modularizing your code is to write code that is modular. Be that in the form of function declarations or immediately-invoked function expressions (IIFEs) which is how most JS modules worked in the pre-ES6 days. Either way, acquaint yourself with the JSDoc standard and always, always document your functions (there are some materials in the main repo to help you get started with that).
Extras
On top of that, the repo includes 45+ modules to play with, accompanied by unit testing examples. The complexity of these modules varies from one-liners for sorting data to mini libraries that push the limits of the Scripting App’s rendering capabilities. Right now, this section contains just under 1,000 source lines of code.
The Gumroad base-repo is the place where you’ll find examples of achieving a full-featured developer experience inside the Scripting app. One that lets you import, export, document, and bundle code as you write it, with minimal distractions.
*I haven’t yet tried On2Air but it sounds like a more elegant, user-friendly way to modularize your Airtable scripts with extra bells and whistles. The catch being it’s a subscription service.
