Storing calculations from expressions in the data model

[olemartinorg]

Description

Early on in the expression language project, it was assumed that expressions would take over from RuleHandler in every way in the future, such that jS-based rules could be deprecated and removed at some point. We're getting closer, but there's one big missing part - doing calculations and storing those in the data model.

Right now there's two main ways to perform calculations:

• Writing a rule in RuleHandler. This will run in app-frontend and can take leaf values, leaf values from repeating groups, and leaf values from nested repeating groups. The output can be stored as a single leaf value.
• Making changes to the data model in ProcessDataWrite on the backend. This is much more flexible, but also binds the frontend tightly to the backend and the data processor there (as an effect, many apps need to save data frequently in order for dynamic effects in the app to occur at all - and consequently a failed save operation cannot be handled gracefully).

Doing this with expressions would introduce a third, and one with benefits over the other two:

• Calculations can be performed on both the frontend and the backend (the latter is important for API users).
• Calculations can be done faster on the frontend (i.e. it doesn't have to wait for the backend to process the saving operation), and we can get closer to a frontend that works offline (at least in a shorter duration in cases where the user has a spotty internet connection, or the app itself is offline for a period of time).

Storing calculation results must not be confused with:

• Just calculating something and showing it to the user (without ever storing it). This can already be done using expressions and the Text, Number and Date components.

During a meeting with SSB today, we discussed this slightly, and talked about a few different solutions:

1. Making a component that takes an expression and stores it in a dataModelBinding. This was mostly inspired by a somewhat bad example I made in Expressions: Using expression value instead of dataModelBinding for components #1178

{
  "id": "myInput",
  "type": "Input",
  "readOnly": true,
  "value": ["sum", 1, 3, 3, ["component", "someNumber"]]
}

It could be argued that slapping on a dataModelBindings in addition to the existing config would make sure this expression value was stored and shown. However, it gets muddy when setting readOnly: false. What happens when the user types into the Input at that point is unclear.

2. As with expression-based validation, create a new configuration file that allows you to have a list of paths in the data model along with expressions that will set data in those paths.

Related issue(s)

• Utvidelse av RuleHandler med støtte for repeterende data i kalkuleringer #1937
• Expressions: Using expression value instead of dataModelBinding for components #1178
• Expressions: List and object support #1179