New tutorials and Pack SDK updates

Making Packs
1

Hello Pack Makers - We’ve continued to roll out some updates to the Pack SDK and documentation over the last few months, and I wanted to give a quick recap for those of you not constantly refreshing the release notes (like I am).

More CLI, less setup

Using the coda CLI to build Packs can be really powerful, but setting up a local development environment can be an epic pain, especially if you are new to the world of command lines, dependencies, etc. However there are a number of great tools out on the market today that make it easy to spin up a virtual, hosted environment with almost no work at all!

We recently published three new tutorials that help you get started with some of the most popular options in this category:

Using the CLI in Replit
Using the CLI in Replit992×684 65.7 KB

If you’ve been itching to try out the CLI but wary of dealing with the installation, give one of these a try and let us know how it goes.

Read text as **markdown**

Coda columns can contain rich text (bold, italic, etc), and for some Pack formulas it is useful to get that formatting information. Previously this could be done by using the Html parameter type, which would pass the HTML-equivalent value of the text to your formula.

However HTML is so 1993, and so we’ve also added a new Markdown parameter type you can use to get the Markdown-equivalent of the text. This can be especially useful if you are integrating with an API that also supports markdown, allowing you to preserve the formatting without any additional work.

Show rich text and HTML and Markdown

Only sync the columns you need

Every once in a while a sync table will come around that includes such an incredibly large number of columns that it will start to cause performance issues (I’m looking at you Jira). Any particular doc is likely only to use a small fraction of those columns however, so syncing them all was kind of overkill.

Now when creating these large tables the user will be prompted to select the specific columns they want to sync, and only those will be included in the object chip.

The sync table column selection dialog
The sync table column selection dialog492×592 51.8 KB

The SDK also includes a new getEffectivePropertyKeysFromSchema() method you can use to determine which fields you need to fetch and streamline your requests to the API. Read more about this change and check out at an example Pack in the Sync tables guide.

Sync fewer rows when testing locally

Being able to run your code locally is one of the huge upsides to using the coda CLI, and it can make it much faster to test small changes. Sync tables however are designed to handle thousands of rows, and depending on the dataset running a sync can be less than speedy.

For this reason the coda execute command was updated to include a new --maxRows flag that allows you to reduce the length of your syncs, and makes it easier to eyeball the output.

$ npx coda execute pack.ts Cats --maxRows=2
[
  {
    Image: 'https://cataas.com/cat/rV1MVEh0Af2Bm4O0',
    Tags: [ 'kitten', 'several', 'gif' ],
    Created: 'Sun May 01 2022 20:57:11 GMT+0000 (Coordinated Universal Time)',
    Id: 'rV1MVEh0Af2Bm4O0'
  },
  {
    Image: 'https://cataas.com/cat/ZHrXPVRJniYPR6pp',
    Tags: [ 'gif' ],
    Created: 'Wed Jun 01 2022 22:29:22 GMT+0000 (Coordinated Universal Time)',
    Id: 'ZHrXPVRJniYPR6pp'
  }
]

Handle redirects your way

The fetcher interface has always aimed to make your HTTP requests user-friendly, with automatic handling for rate limits, parsing JSON, etc. This also include following redirects, which means when it gets a 301 or 302 response with the new location for a resource the fetcher will go ahead and fetch it automatically.

This behavior is probably want you want 99% of the time, but in rare cases you may need to pause, inspect the response in more detail, and perhaps handle it differently. To allow for this we now have an ignoreRedirects option in the fetcher request that will tell the fetcher to tap the brakes if it gets a redirect and just return the response.

let response = await context.fetcher.fetch({
  method: "GET",
  url: "https://coda.io/request-a-pack",
  ignoreRedirects: true,
});
console.log(response.headers.location);

Less guessing in the OAuth flow

OAuth is the lovely “standard” that is used by most APIs to sign in a user, but often each app will put its own spin on it to keep life interesting. The Packs platform does its best to hide most of the gory details from you, but occasionally you may be required to provide a little extra detail.

One such area where your guidance may be required is how Coda should pass the application credentials (client ID and secret) to the API when it’s fetching a token. Some APIs want those credentials in the request body, others encoded in an Authorization: Basic header. Previously Coda would try one, and if that failed try the other, but some APIs got grumpy when they were sent the same authorization code twice.

To address this you can now explicitly set how you want these credentials passed, avoiding the guess work. Simply pass a value for credentialsLocation, selecting from one of the TokenExchangeCredentialsLocation options.

pack.setUserAuthentication({
  type: coda.AuthenticationType.OAuth2,
  authorizationUrl: "https://todoist.com/oauth/authorize",
  tokenUrl: "https://todoist.com/oauth/access_token",
  credentialsLocation: coda.TokenExchangeCredentialsLocation.Body,
});

That’s it for now! Let us know if you have any questions or feedback about these changes, and happy Pack making!

9 Likes