#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

[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]

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 this line means that every view response has a required dataByAlias field? But View::jsonSerialize() in lib/Db/View.php does not return dataByAlias. I'm confused

[samin-z]

dataByAlias field is always present in row api responses, the code that builds these responses ensures it regardless of technicalName. the confusion here is because View::jsonSerialize() is unrelated to row serialization. the type definition is correct and we do not need to make dataByAlias optional unless we expect future changes that could remove it.
you can check it locally and if there is a case which i missed, please let me know.

[nimishavijay]

Yes, this makes sense! would it be possible to make it collapsible and hide it by default? like the files sharing settings?

I also realize that this is moving towards a bigger redesign of the "edit column" modal so also pinging @marcoambrosini here

[samin-z]

@nimishavijay i thought about it, but since it's a new feature it's possible users might miss it. so for better user accessibility and until users get used to it i thought to leave it out in the open and in later version to improve it, what do you think?