Expressions: Extend with more functionality

[olemartinorg]

In the layout expressions project we have intentionally set the bar fairly low, in order to get to a basic implementation faster. As planned for the first release, layout expressions can only be used to evaluate to a boolean value. On the backend, only the hidden and required properties for layout components will be evaluated, while the frontend will evaluate other properties like readOnly and various properties in the edit properties for groups.

This issue tracks extensions to these expressions we've thought of, but won't necessarily arrive in the first version. These tasks should probably be extracted to separate issues when/if we start working on them, if the efforts to implement them are large enough.

• Recursive layout expressions

Passing an expression as an argument to an expression can be useful for more advanced logic. If we're implementing this, adding functions for and and or (both with any amount of arguments) is a given. An example of a recursive expression:

{
  "hidden": ["and",
    ["component", "some-other-component"],
    ["or",
      ["dataModel", "MyModel.Path"],
      ["dataModel", "MyModel.Alternative.Path"],
      ["dataModel", "MyModel.Third.Alternative.Path"],
    ]
  ]
}

• Expressions returning strings/non-booleans

We could also use expressions for conditionally swap out labels/texts in textResourceBindings, etc. If we do, there should probably also be function(s) to map known data model (etc) values to the appropriate text resource keys, handle the default case if no mapping is valid, etc. We should also implement functions like concat, toUpperCase, etc, for simple string manipulations. There would also be a use-case for the most basic function (possibly even implicit) where an argument is return verbatim (i.e. a lookup function):

{
  "textResourceBindings": {
    "title": "myTitle",
    "description": ["dataModel", "MyModel.Description"]
  }
}

• Using expressions for values/calculations Moved to Expressions: Using expression value instead of dataModelBinding for components #1178 and Expressions: New simple functions #1176

We could possibly replace existing implementations for calculations with layout expressions as well. Care needs to be taken to ensure we don't restrict functionality in a way that makes it impossible to implement existing calculations that are already implemented in some apps - we'd like for a frictionless upgrade path to make use of layout expressions instead of RuleHandler.js.

Careful thought should go into designing this in a way that makes it easy (or at least possible) to implement calculations for rows in a repeating group (respecting potentially hidden/filtered rows). See discussion on Slack here. It should also be possible to implement a function for counting the number of rows in a repeating group.

One advantage to using expressions for calculation is automatic API support and possibly valdation to avoid client-side tampering (if implemented on the backend).

Example for a sum implementation:

{
  "id": "total",
  "type": "Input",
  "readOnly": true,
  "value": ["sum",
    ["component", "value1"],
    ["component", "value2"],
    ["component", "value3"]
  ]
}

Or concatenating strings to present a full name:

{
  "id": "fullName",
  "type": "Input",
  "readOnly": true,
  "value": ["concat",
    ["component", "lastName"],
    ", ",
    ["component", "firstName"]
  ]
}

• Using expressions for custom validations Moved to Validering ved hjelp av dynamikk #726

This requires both validation (a boolean, in principle) and a validation message (a string, which could perform a lookup in text resources). We would also have to support soft validations. Consider if we should use a prefix like *WARNING* like we do today, or implement this using a custom not-just-string data type.

• More argument types: Shadow fields (no need, shadow fields live inside the data model)

When we have an implementation for shadow fields, we should support lookup up those values.

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

Large expressions should be possible to re-use. Either by separating them out to definitions (similar to a structure like in JsonSchema) and referencing them from there, or by implementing functions to directly reference other expressions:

{
  "id": "dependsOnSomethingElse",
  "type": "Input",
  "hidden": ["isHidden", ["component", "someOtherComponent"]]
}

Or, more generically:

{
  "id": "dependsOnSomethingElse",
  "type": "Input",
  "hidden": [
    "equals",
    ["getProperty", ["component", "someOtherComponent"], "hidden"],
    true
  ]
}

• Hiding an entire row in a repeating group (see Repeating groups: Kunne sette opp logikk for å skjule en eller flere rader i en repeterende gruppe #389)

A likely need/want is to use layout expressions to hide an entire repeating group row, possibly based on some data within it. This type of dynamic should be placed on the group component, and would in effect hide all components inside that row. It is an outstanding question if this should lead to the entire row being deleted when submitting the data, if this should not happen, or if it should be configurable.

See discussion on Slack

• ~~New function: contains (and support for lists/arrays, with a list function) ~~ Moved to Expressions: New simple functions #1176

A much-discussed need is a function that allows you to check if a value is in a list of values. This is needed to assert if a certain checkbox has been checked, but as long as #273 is unsolved, this would also require support for comma-separated values. An alternative is creating a temporary function for this exact case (inCheckboxValue or inCommaSeparatedList).

See discussion on Slack

• New function: in Moved to Expressions: New simple functions #1176

Shortcut function similar to equals, but compares the first argument against multiple others to check if the first argument matches either one of them.

See discussion on Slack

• New function: text Moved to Expressions: New simple functions #1176

Function used to look up a text resource key, resolving to the value of it. This is not really that relevant for backend code, so perhaps we could limit this so it's only possible to use it in frontend-evaluated expressions.

• New function: language Moved to Expressions: New simple functions #1176

Function used to look up the current language (nb, en, etc).

[xmrsa]

It is important that the "hidden"-parameter also allows expressions like "contains" and "notContains" in addition to the existing "equals" and "notEquals". Please make sure that null-values can be allowed so you can add a new row to a repeating group without it disappearing. Every field in the new row is null until you write and save something there.

[olemartinorg]

Very relevant:

• As an app developer I want to show the display value as a variable in text #1105 (comment)

[olemartinorg]

All of the functionality described above has now been moved into more detailed issues, which are meant to be bite-sized so that we can start implementing them.

• Repeating groups: Kunne sette opp logikk for å skjule en eller flere rader i en repeterende gruppe #389
• Validering ved hjelp av dynamikk #726
• Expressions: New simple functions #1176
• Expressions: Allow for re-use of expressions #1177
• Expressions: Using expression value instead of dataModelBinding for components #1178
• Expressions: List and object support #1179
• Expressions: Support options from expression result #1180
• Expressions: Using expressions as mapping (aka query parameters) #1181