Feature request: better interoperability with native Coda objects

Some of this has already been suggested or touched own by the team at the latest AMA webinar, and I thought it would be helpful to recap those there in addition to new ones.

Feature requests:

  • ability to pass coda objects to pack building blocks, namely being able to pass rows, tables, columns, pages, etc. directly as arguments for pack parameters. As already mentioned, on the technical side, passing these as copies of the data (at least directly) is probably infeasible, so a more realistic experience would be to receive references to these objects (probably urls, else some typed object with an id), which can be used to query the API for the data on demand. The use case is that there are already several such packs that make use of doc objects, but rely on more niche ways of bringing these into the doc, such as copying urls.
  • ability to reference other tables as reference columns in pack sync tables. This would improve how sync tables that operate on coda objects integrate into docs.

I think altogether these features would enable higher level packs that instead of operating on data within doc elements, operate on doc elements themselves. I would see these as almost doc-builders or pre-baked automations to solve common and domain-specific patterns. Instead of just providing a table with an integration and requiring the user to glue it to their own data, to also be able to take in other tables of the doc as inputs and apply patterns and include them in the integration automatically.

2 Likes

Thanks @louca.developer for recoding this request and for including so much detail. One tension, at least in my mind, is to what degree is it useful to keep logic in the doc layer, vs the Pack layer. While a Pack that could read and/or manipulate your entire doc is very powerful and perhaps easy to use, it’s logic is locked within the Pack’s source code and unavailable for the maker to tinker with. One of the advantages of the current Packs approach (although it does come with a learning curve) is that makers remain in the driver seat, and can control what data a Pack is using stich things together in new ways.

2 Likes