Row UID with Pack

Making Packs
1

I’m guessing the community has tried this before, so thought I’d ask.

We can get Coda’s UID for a row with the following formula:

ParseJSON(thisRow._Merge() + "","$.identifier")

If I wanted to get this identifier using a Pack, how would you suggest I go about it?

2

Maybe I am missing the point, but how would a pack have access to this kind of information? You can send it to the pack as a parameter, but once a pack function is activated, it is agnostic of the Doc until it sends something back.

I am not a pack specialist, but I think what you are asking is not possible.

3

Hi @Brian_Sowards - No, unfortunately a Pack wouldn’t be able to produce that UID. The main reason is that Packs don’t have direct access to the content of your docs, and there is no way to pass an entire row to a Pack as a parameter.

4

I’m using a different formula, Split(thisRow + "", "/").Last() for the UID.

There’s also a hidden formula, _ROW_KEY(), that returns the $$[] notation of a reference; splitting it by : and taking the 4th element will also give you the row ID:
image
(I don’t think I ever mentioned it earlier)

What does passing thisRow to a pack do? Is it passed as the text value of the display column, or does it turn that into a grid/row ID?

Why need a pack if both your and mine formulas work fine and instantly?

1 Like
5

Today if you pass anything to a String parameter that isn’t a string we just automatically apply .ToText() to it. For a row I believe this will give you the value in the display column.

1 Like
6

I think I can make the pack. . . Had a brain blast this evening

7

Nice Scott! I’m looking to use the functionality in another pack. Game to open source or collab?

8

Original question though is still interesting - why would you want this outputted by a pack when many other better ways exist?

9

Mainly to avoid users needing to enter formulas as opaque as the one at the top. Do you have a preferred approach?

10

I can only think of two ways that look like a “user-friendliness” improvement over the “opaque formulas”:

  1. Pass thisRow + "" to a Pack; at this point the pack will simply handle the Split().Last()
    image

    (don’t mind the output; I made the function to just echo the input)

  2. Pass thisRow.ObjectLink() and have the pack call Coda API, locate the table and the row within that table, and return the row’s ID. Looks the nicest to the users but holy hell, it’s basically two API requests to the Coda API (resolve browser link and get row) all for nothing!
    image

Looking to learn what Scott came up with

2 Likes
11

I think exposing some metadata to Pack formulas would be awesome.

For example, if a formula is inside a row, pass the table and row ids as metadata.

3 Likes
12

My idea was essentially yours Paul - the multiple api calls

But not going to build it, because it seems so silly and there’s already way better methods of grabbing these ids.

13

Thanks Paul, the 2nd option is what I was imagining the solution might be but agree that a double API call is not optimal!

14

What would you consider to be the better approach Scott?

15

I agree with that. Passing the context (thisRow location for a button / column formula) would be great — not the data but at least the row URL or any other similar identifier. I needed this for Sync Tables Pro too. The identifier wouldn’t expose anything because it’s useless without access to coda.io network domain anyway, but would help a lot with building packs for the Coda API.

Also @Eric_Koleda could you maybe consider not .ToText()-ing references that are passed as references? To get the text value one can always dereference the required column or .ToText() manually — is there a reason to automatically ToText() those?

2 Likes
16

The formulas already suggested here!

And user education to help them construct or understand those formulas

If the Main issue is “those formulas are too hard to write” then let’s solve for that issue. Educate and empower

1 Like
17

There is actually a UID pack in the gallery already; what it does is it gives you a sync table of basically all rows from a selected table but with a UID column.

But this is already cross-doc territory (sledgehammer basically). Cross-doc also exposes “row URL” that has the UID. My pack does it too with the “Origin ID” column if it’s not overridden.

18

This happens in the Coda formula language before it gets to the Pack infrastructure, so it wouldn’t be easy to change. Long term I’d love for us to have a Row or Table parameter type meant for accepting these objects directly, and in your Pack you would receive at least the metadata if not the values.

2 Likes
19

Interesting. I’m trying to minimize the effort for the user in getting this value so stayed away from cross-doc (which we’ve also found to be pretty buggy/unreliable). I’m excited to try out Sync Table Pro!

Appreciate the contributions everyone.

20

we have had the same issue - get the user to provide the ThisRow context to a formula as easily as possible.

in our Coda VBA translation pack, the user provides ThisRow to the interpreter by adding it to the start of the code they want to execute like this;

VBA(ThisRow+myVbaCode) // note the PLUS

this appends the grid reference to the start of the text which the interpreter picks up and uses to provide the correct context during execution.

note that this NOT the same as giving 2 parameters; VBA(ThisRow, myVbaCode) //not the same

because ThisRow+“” causes the grid reference to be returned as text. our interpreter parses out the grid reference as the ThisTable ‘;’ ThisRow and uses those to ensure the code is interpreted appropriately.

max

1 Like