Expressions: Engine

[olemartinorg]

Description

Splitting up the massive #540 into smaller parts. After #553 and #554, this PR is the big one with the whole engine for evaluating expressions, and everything needed to at last implement support for expressions in app-frontend-react. The last PR will utilize the functionality implemented here into GenericComponent etc (and that PR will arrive when this has been merged).

The overview of the functionality in this PR can be seen from the folder structure:

• The expression engine in src/features/expressions
  • The runtime expression evaluation engine, with functions and type-casting in index.ts
  • prettyErrors, which allows for listing multiple errors deep into a structured object and printing them colored to the console
  • useExpressions as a react hook, which lets you evaluate expressions (also inside an object) in your component
  • Validation code to make sure expressions are well-formed at the point they are loaded from layout files (gives an error message if expressions are invalid, and replaces the expression with a default value).
  • Shared tests for the expressions engine
• Utilities for traversing and mutating the string in a data model binding in src/utils/databindings/Databinding.ts
• Utilities for converting a flat layout to a hierarchical structure in src/utils/layout/hierarchy*
• React hooks for reading the entire layout (or all layouts), converting them to a hierarchical structure and (optionally) resolve expressions inside the nodes.

A core concept in this structure is a new term for app-frontend-react; a node. Currently we have used the name component for the components defined in the layout definitions. And we often refer to a specific component, even when that component is possibly rendered multiple times (in a repeating group). I use the term node here for that case - and my definition of a node is that it's an instance of a component (for which there might be multiple nodes when dealing with repeating groups).

The work around converting a flat layout into a hierarchical structure with nodes as component instances can be seen as a precursor to what's needed to implement #345. The tools in src/utils/layout/hierarchy* are optional now, and will be used in expressions and validation, but in time I believe these concepts should replace the structure of our current redux store and should be used everywhere.

Related Issue(s)

• Expressions #540
• Logic/expressions in layout #355

Verification

• Your code builds clean without any errors or warnings
• Manual testing done (required)
• Relevant automated test added (if you find this hard, leave it and we'll help out)
• All tests run green

Documentation

• [ ] User documentation is updated with a separate linked PR in altinn-studio-docs. (if applicable)

[sonarqubecloud]

Kudos, SonarCloud Quality Gate passed!   

0 Bugs
0 Vulnerabilities
0 Security Hotspots
2 Code Smells

90.6% Coverage
0.0% Duplication

[bjosttveit]

Sett igjennom så mye jeg klarer, så bra veldig ut 🙌 🙌