#1840: API structure improvement: expose columns through a technical name/slug/alias

[samin-z]

Feature ticket: #1840

New response structure:

data: [
    {
        columnId: 70,
        value: 11
    },
    {
        columnId: 72,
        value: 3
    },
    {
        columnId: 76,
        value: [
            {
                id: user1,
                type: 0,
                displayName: user1
            }
        ]
    }
],
dataByAlias: {
    column_70: {
        columnId: 70,
        value: 11
    },
    column_72: {
        columnId: 72,
        value: 3
    },
    test_customer: {
        columnId: 76,
        value: [
            {
                id: user1,
                type: 0,
                displayName: user1
            }
        ]
    }
}

now we have new field added to columns called 'technical_name' which if user does not add it as default will be 'column_{id}', 'dataByAlias' added on top of 'data' not to break the current structure.

[enjeck]

some comments

[enjeck]

Looking at #1840, in order for this to be useful for workflows, we must expose it via AbstractRowEvent.php -> toPublicRow() ?

[enjeck]

I believe we're now doing 2 writes? Both create() and importColumn() create a column first and only then assign the fallback column_ name. If the second write fails, the request throws after the insert has already succeeded, so we leave behind a persisted column without the technicalName. Maybe we should have a transaction then?

[samin-z]

there is no problem even if the update of technicalName fails a 'null' value for the column is valid. When 'technicalName' is null, the code in RowService handles it:
$alias = $aliasByColumnId[$columnId] ?? ('column_' . $columnId);
this causes the column to behave correctly with the 'column_{columnId}' fallback.
also when the user edits and saves the column, the 'null' will be updated with either their chosen value or the default 'column_{columnId}'.

[enjeck]

used here and in CreateColumn, could be moved to a shared file and reused

[enjeck]

we return false for null technicalName when we edit but true for creating? Why?

[samin-z]

that wa my mistake as i was going through it and forgot to update

[Koc]

hey @samin-z!

Thank you so much for taking care of this. I've just opened similar PR for Views #2547.

Few ideas that came to my mind when I worked on it:

1. as this technical name is some kind of "advanced" feature used mostly by developers - then I moved it under special "spoiler" in order to not to burden the UI for regular users

2. as changes to this field can broke API/integrations - then I added some notice on change

WDYT about adding same things to your PR?

[samin-z]

i compared playwright fails against main, failures are in known flaky datetime/login/navigation tests and are reproducible outside this branch, none of the failures point to technical_name or dataByAlias code paths.

[samin-z]

@nimishavijay

now we have advanced setting to column edit/create

does this setup align with what design had in mind or exact design for "table view"?

[enjeck]

some comments

[enjeck]

Did you test out the webbook event to see what the payload is? Cuz from the code, it seems like above we dispatch the event with new RowUpdatedEvent($updatedRow, $previousData) before even attaching dataByAlias? So webhook results doesn't get the dataByAlias value?

[samin-z]

you're right, fixed it in RowService by ensuring alias payload is attached before event dispatch.

[enjeck]

should this be optional

[samin-z]

i'de keep it as none optional, the row serializer always returns this key and it gets normalized to an array, so clients get a stable contract anyway.

[enjeck]

I think status 400 is better, not 500

[samin-z]

it is returning 400