Suggestion: add coda.api to default coda import in SDK

Making Packs
1

I know that y’all restrict outgoing domains to a single endpoint right now, but I think it would be really powerful if you made an exception for your own API endpoints. It would be useful if I could do something like:

import * as coda from "@codahq/packs-sdk"
const { api } = coda
const table = api.getTable(docID, tableID)

This would enable some powerful new behaviors, like dynamically adding rows to tables via pack code. I know you have some security concerns so perhaps this could be a limited subset of your API?

I know you don’t have a public NPM library for your API but there are two on NPM you could wrap or you could expose your own fairly quickly.

4 Likes
2

Thanks so much for the suggestion! I’ve also found that Packs plus the API open up a lot of interesting avenues. I think security concerns are going to be an issue, as building user trust around 3rd party Packs is an important goal of ours. I’ll mention this feedback to the team though, as I think it’s important to start thinking about could be possible.

3

As a follow-up, would you be willing to share more about a specific use case you’d want to solve with the API in Packs? We suspect that some of the things folks would want to use the API for would be better built into the Packs SDK itself.

4

Some examples of things I’d like to be able to do in a Pack:

  1. Write an action that takes a docID and tableID and a payload object and adds a new row to the table from the payload object. This can be done easily enough using Coda normally, but if you’re writing complex data you’ll end up putting a ton of logic, including conditionals and branching paths, into the formula editor. Stuff like that is brittle and better suited for a more testable language – I’d love to be able to write this formula in JavaScript and capture that behavior in a pack.

  2. Dynamic reads! Sometimes I want to read a column’s value from a table, but which column I read depends on some other logic. I can’t right now as far as I’ve found do a dynamic column name lookup in a coda formula, something like .“string_column_name”. But if I had access to the coda API inside of the pack builder I could write a formula that gives me the data I’m looking for. Basically it would take DocID, TableID and Column Name and return that column’s data.

  3. Push-based cross-doc behaviors. Cross-Doc is nice but relies on polling to get updates over time. With this feature enabled in the Pack Builder you could write a method which copies a row from a table in one document to a different table in a different document, for instance, and that would happen in real-time as the formula runs.

These are just some thoughts off the top of my head. Basically anything that lets me pull brittle switch statements out of the formula editor and into javascript is a win; anything that lets me read dynamic data is a win; and anything that empowers push-based cross-doc interop is a win.

Adding the coda API to the pack builder feels like a win/win/win situation, and a really easy first step is just making it so that you can use the Coda API Endpoint in addition to whatever allow-listed third party domain you’re using in your pack. Then you can add api methods in a subsequent update.

2 Likes
5

This would be great ! :smiley: