Custom properties/fields in code lists

[olemartinorg]

Description

As of now, the AppOption class accepts four fields:

• value
• label
• description (optional)
• helpText (optional)

We should remove this restriction to allow for any amount of key/value data in this object.

Background

When we talked about the naming of this concept of 'code lists' / options, @altinnadmin said:

Svaralternativer etc blir fort litt begrensende i forhold til den opprinnelige tanken bak kodelister. Man kan benytte en kodeliste som svaralternativer i en skjemakontekst, men de er ikke begrenset til det, og de "er" ikke det.
Kodelister tilbyr data med en en unik identifikator (koden) som refererer til en eller flere verdier via API. F.eks. en kodeliste med kommuner som også inneholder info om fylke slik at man enkelt kan lage f.eks. filtrering av kommuner basert på fylke, og vedlikeholde disse koblingene ett sted når kommuner slås sammen, uten behov for å hardkode disse i hver eneste app/tjeneste.

This ties into the keyValuePairs passed to the IAppOptionsProvider. It's possible to send query parameters, but if it's only for filtering which municipality you should be able to select depending on the county, simply returning all options from the API and filtering in frontend would be more effective:

[
  {
    "value": "1103",
    "label": "Stavanger",
    "county": "Rogaland"
  },
  {
    "value": "1201",
    "label": "Bergen",
    "county": "Vestland"
  }
]

Now that filtering via expressions is available, you could set this up with:

{
   "id": "choose-municipality",
   "type": "Dropdown",
   "optionId": "municipalities",
   "optionFilter": ["equals", ["value", "county"], ["component", "choose-county"]]
}

[ivarne]

Looks reasonable to support filtering in frontend all the way.

Only comment here, is that when we add [JsonExtensionData] public Dictionary<string, string> ExtensionData, it becomes questionable to add more properties, so we should be sure that value, label, description and helpText are everything we want to support. Do we want to add CustomTextKey and CustomTextParams as we have in validation issues?

[olemartinorg]

so we should be sure that value, label, description and helpText are everything we want to support

Good point. If we go down this path, will it become impossible to add new properties, or will the new properties just override the custom ones? I.e. making a new property a breaking change?

Do we want to add CustomTextKey and CustomTextParams as we have in validation issues?

All texts in options already support translations by adding text resources matching them. The label, description and helpText fields are already doing this. Maybe I'm not entirely understanding the need for this in validation, but I don't see why options would need new keys like that, no.

[ivarne]

I.e. making a new property a breaking change?

Yes, if someone used that name, we’ll be in trouble.

but I don't see why options would need new keys like that, no.

I currently don’t see why either, but it was the most reasonable extension I could think of.