Dynamiske uttrykk: Mulighet til å vise tekst fra skjult felt

[StianVestli]

Description

Man har i dag muligheten til å hente ut visningstekster fra komponenter via dynamiske uttrykk:
["displayValue", "component-id"]
Vi bruker en del prefill data som vi vil presentere for brukeren gjerne da som tekst. For å få denne teksten formatert så vil vi kunne sette denne til et inputfelt og så legge dette skjult for brukeren. Problemet i dag er da at vi ikke kan hente ut dislayValue.

Vi trenger å kunne hente ut : ["hiddenDisplayValue", "component-id"]

Avhengig av Altinn/app-lib-dotnet#1157

Denne oppgaven kan ansees å være avhengig av Altinn/app-lib-dotnet#1157. Når vi uansett "fjerner data" for skjulte komponenter vil uansett oppslag av displayValue (og component-oppslag) påvirkes av dette. Det som da blir riktig oppførsel er jo å vise skjult data på samme måte som resten av skjemamotoren gjør - for selv om komponenten er skjult, kan den ha en verdi (f.eks. preutfyllt ved oppretting av datamodellen) som vi ikke skal slette (for vi skal i utgangspunktet bare slette data brukeren har fyllt ut, og det vil også si at vi må "rulle tilbake" til slik datamodellen var før brukeren gjorde endringer når brukeren har gjort slik at komponentene ble skjult).

Med andre ord, opter man inn for å bruke funksjonaliteten i Altinn/app-lib-dotnet#1157 er det også naturlig at vi fjerner denne begrensningen som gjør at displayValue og component funksjonene i uttrykk gir tom verdi om man spør etter skjulte komponenter.

Oppdatering, 10.01.2025: Nå ser Altinn/app-lib-dotnet#1157 ut til å dreie i en litt annen retning (da dette nok heller blir implementert på backend), og da blir det ikke hensiktsmessig å gjøre seg avhengig av en tenkt løsning der (når uttrykkene må kunne kjøre i frontend).

Additional Information

• Form data: Remove hidden values app-lib-dotnet#1157
• Add formatting to key-references in resource-files #2287

[olemartinorg]

Vi diskuterte denne på statusmøtet i dag 20. mars, og det kom frem at behovet her kanskje i like stor grad er å kunne tall-formattere noe man henter fra datamodellen direkte. Men dette gjelder jo også f.eks. option-lister, og da måtte man kunne hatt støtte for å vise frem en label for en gitt option-verdi.

Så selve behovet her er gjerne å kunne vise slik tekst, via uttrykk, med eller uten å konfigurere opp en skjult komponent for å beskrive hvordan man skal formattere visningsdataene.

[olemartinorg]

Diskutert i møte. Denne har et visst overlapp med optionLabel-funksjonen (beskrevet i #1299) og en mulighet for å bruke tallformattering (og datoformattering?) i uttrykk.

Eksempel use-case: Kunne hente ut label fra en kodeliste for bruk som "suffix" på et tallformatteringsfelt (f.eks. repgrupper hvor man har forskjellige enheter basert på verdier i raden).

[olemartinorg]

Jeg gjør et nytt forsøk på spesifisere opp en løsning her. Ut ifra kommentarene over har vi 3 forskjellige use-cases:

1. Formattere en dato vha. et uttrykk Dette finnes allerede med formatDate-funksjonen.
   • Her er det sikkert lurt med et godt default-format.
   • Når man skal ha flere argumenter her blir det fort ulogisk med posisjonsbaserte argumenter. Gitt f.eks. ["formatDate", ["dataModel", "Prefill.StartDato"], ???] skal da ??? representere er argument for "inkluder tidspunkt i tillegg til dato", eller skal man skrive inn eget format der? Kanskje det kan bety begge - altså at true|false betyr om tidspunkt skal vises, mens en streng betyr at man vil bruke sitt eget datoformat. Dette er gjensidig utelukkende med en boolsk 'inkluder tidspunkt'.
   • Et bedre alternativ til flere argumenter kan være å dele dette opp i to funksjoner: formatDate og formatDateTime. Hvis du kan legge til et eget format på begge disse kan du jo også få dem til å oppføre seg likt (["formatDateTime", [...], "DD/MM/YYYY"] gir deg bare dato selv om du har oppgitt at du vil ha med tidspunkt - men kanskje formatDateTime hinter til at selve verdien er oppgitt med tidspunkt, ikke at visningen skal inneholde tidspunkt).
2. Formattere et tall
   • Oisann. Egenskapene for formattering av tall er nå ganske sterkt knyttet til et objekt, altså det du gir til formatting-egenskapen i en Input-komponent. Med andre ord trenger vi Expressions: List and object support #1179
3. Hente ut label/ledetekst for en option/kodeliste-alternativ Implementert og lansert (optionLabel-funksjon)
   • Her kan det jo tenkes at man også skulle kunne hente ut beskrivelse eller hjelpetekst, eller hva som helst: Custom properties/fields in code lists app-lib-dotnet#996
   • En mulighet (istedenfor å lage optionLabel) å implementere Expressions: List and object support #1179 og la deg plukke ut ledeteksten selv med et uttrykk som:
     • ["text", ["pluck", "label", ["first", ["options", "myOptionsId"], ["equals", ["item", "value"], "myValue"]]]]
     • Hvis vi lager slike kraftige (men verbose) verktøy, øker det jo raskt behovet for gjenbruk: Expressions: Allow for re-use of expressions altinn-studio#16764
   • Hvis vi skal lage optionLabel-funksjonen, ser jeg for meg signaturen kan være en av disse:
     1. ["optionLabel", "component-id-with-options", "some-option-value"]
        • Fordeler: Mye enklere å implementere i frontend, kan fungere uansett kilde (også fra repgruppe, statisk liste osv)
        • Ulemper: Man må kanskje konfigurere opp en komponent og gjøre den skjult dersom ingen andre komponenter egner seg.
     2. ["optionLabel", "code-list-id", "some-option-value"]
        • Fordeler: Enkere å forholde seg til dersom man ikke har en komponent som allerede bruker denne listen
        • Ulemper: Vanskeligere å implementere i frontend (eller, egentlig bare kjipere, for vi må passe på at vi henter listen før vi starter å kjøre uttrykk - så kodeliste-iden kan foreløpig heller ikke være dynamisk). Begrensende om man bruker options fra f.eks. repgruppe eller en statisk liste.
     3. ["optionLabel", { full object with option configuration }, "some-option-value"]
        • Fordeler: Støtter alle typer kodelister og opsjoner, uavhengig av eksisterende komponenter.
        • Ulemper:
          • Krever støtte for objekter i uttrykk.
          • Man må kanskje kopiere mye config fra komponenter om man har et komplisert oppsett.
          • Ikke sikkert kodelister fra source er helt nødvendig her, siden man like godt kan hente direkte fra datamodellen om man har støtte for lister og objekter i uttrykk.
          • Krever potensielt komplisert kode for å få til i frontend, eventuelt en form for async/await i uttrykk (for å støtte f.eks. mapping og henting av ny kodeliste basert på spørringsparametre).
          • Kan bli stort og vanskelig å lese.