Expressions: Using expression value instead of dataModelBinding for components

[olemartinorg]

With the expressions language becoming increasingly feature-rich, we should allow components to get their form data value (in a read-only way) from an expression result, rather than from a normal data model binding. This means that we can create read-only fields in a form that performs calculation via expressions and shows the result without storing that result in the data model.

Things we should think about:

• Try to make the implementation as component-agnostic as possible. We don't want to have to implement this again and again for every new component that should have a value bound to them. It might be better to hide this fact from the component and ignore update requests in GenericComponent, thus letting the component pretend the value came from the data model.
• If the component is also bound to the data model, we should probably insert/set the data there for every calculation/expression result change. The backend should do its own calculation and override the values in the data model we set.
• If another expression does a ["component", ...] lookup on us, the expression result value should be returned (if the component is not hidden), even if it isn't saved in the data model.
• Should we support components with multiple data model bindings, such as address?

Suggested configuration:

{
  "id": "myInput",
  "type": "Input",
  "readOnly": true,
  "value": ["dataModel", "somePath"]
}

[StianVestli]

Man trenger muligheten til å angi enkle beregninger og kunne gjøre sjekker mot disse , ikke bare SUM men å dele to verdier og kunne sjekke på dette, summerer flere og trekke fra mot et annet og sjekke på resultatet osv.

[olemartinorg]

Sjekk = validering? 🤔 Eller hva mener du med å sjekke mot et resultat av en beregning? Fint om du har noen konkrete eksempler på hva som trengs, men det høres potensielt ut som et nytt issue (dog noe vi sannsynligvis bør se i sammenheng med dette).

[StianVestli]

Ja var sikkert noe uklar som vanlig. Man har til tider behov for å kunne sjekke to eller flere tall opp mot hverandre. Feks man angi en mengde av en ting og kostnaden. Man vil da dele dette og bruke resultat i feks en kontroll for å si noe om kostandene er uvanlig lave eller høye. Eller man vil gjøre en beregning og vise resultatet.

For eks noe slik:
{ "message": "Veldig høy stk pris, kontroller mengde og pris", "severity": "error", "condition": ["greaterThan",["calc",["sum", ["component", "someMengde0"], ["component", "someMengde1"]],"/",["sum", ["component", "someNumber1"], ["component", "someNumber2"]]],10] }

Men man vil bruke dette som summering å kunne vise verdien og.
Ga det mer mening?

[ivarne]

Så du vil ha kalkulerte verdier i valideringsmeldinger?

[StianVestli]

Ikke i meldingsteksten, men i grunnlaget for selve sjekken så er det ofte flere verdier sammen som utgjør en kontroll. Alternativet i dag er frontend/backend kalkulering og lagre resultatet i et eget felt i datamodellen for å få til dette.

[olemartinorg]

Det høres ut som det er denne issuen du er på jakt etter da (der ligger også sum-funksjonen):

• Expressions: List and object support #1179

Muligens kombinert med denne, hvis du vil slippe å definere uttrykket to ganger (en gang for å vise det, en annen gang for å bruke det i validering):

• Expressions: Allow for re-use of expressions #1177

[olemartinorg]

Behovet beskrevet i dette opprinnelige issuet anser jeg nå som løst med de nye Text, Number og Date-komponentene. Vi ser også på å lage en Option-komponent for å vise en valgt verdi fra en kodeliste i #2752.

Akkurat dette behovet du har nevnt rundt kalkulering i expression-validering, Stian, tenker jeg bør knyttes til #1179 og de foreslåtte expression-funksjonene beskrevet der.

[olemartinorg]

Lukker denne, da dette behovet dekkes bedre av Text og Number.

Diskutert med SSB, gjenværende behov for dem er:

• Støtte for sum-expression: Expressions: List and object support #1179
• Utvidelse av RuleHandler med støtte for repeterende data i kalkuleringer #1937
• Eventuelt en mulighet for å skrive til datamodellen basert på et uttrykk (trenger et issue på dette, gjerne med et use-case, om det ikke blir løsningen på Utvidelse av RuleHandler med støtte for repeterende data i kalkuleringer #1937)
  • Issue opprettet: Storing calculations from expressions in the data model #2768