Analysis: Shadow fields/helper fields

[nkylstad]

This is a specification task, related to Altinn/app-frontend-react#744.
We need to determine what to support, and how we are going to support it.
Specifically:

• What is supported in Altinn 2?
• Are there needs/requirements outside of what is supported in A2?
• Where should such data be stored?
• Do we need to persist the data once the instance is completed?
• Should this type of data be bound to a specific task, or available across the entire process?

Overview of possible solutions.

1. Shadow fields as part of the data model - The Altinn 2 way

Shadow fields must be defined as a part of the data model, with a specific naming convention. On process next, the app template automatically removes the shadow fields from the form data, so that these are not submitted.

Pros

• This is the way app developers have done it so far (minus the clearing of data on submit)
• This is a known method from Altinn 2
• A strongly typed model to refer to in app logic
• Should be quite straightforward and not time consuming to implement
• Can use existing APIs for storing/fetching data (@olemartinorg Also modifying data in runtime using ProcessDataWrite)
• @olemartinorg: Works with existing structures for repeating group rows
• No need to make any changes to app-frontend

Cons

• The data model will be bloated/contain fields that are never submitted
• Shadow field data is only available within current task
• We modify data that the user is submitting, possible source of errors?
  • Is it ok to modify the data after the user has submitted? (OMH: Yes, we do that already, look below)
• If the user needs to go back to a previous task, shadow field data will not be available (or must be re-generated)
  • @olemartinorg: Unless we delete on process end instead of on task end, as we support already when deleting data from hidden components in expressions

2. Explicitly define a data model for shadow fields

Similar to the above solution, but here the app developer must define a separate data model for shadow fields.

Pros

• Similar to known method from Altinn 2
• Strongly typed model to refer to in logic
• The shadow field data will be separate from form data, so no post-processing is necessary
• Should be possible to set up the shadow field data to be available accross tasks (since it is not deleted)
• Can use existing APIs for storing/fetching data

Cons

• Would require supporting multiple data models per task, which is potentially a big undertaking
• Still require app developers to explicitly define data model for shadow fields
• Need to determine what to do with the data once the process is complete
• @olemartinorg: Requires app-developer to keep a mapping in sync when adding/removing repeating group rows

3. No data model for shadow fields

Allow shadow fields to be stored as a generic set of key-value-pairs. This way there is no need to create data model for shadow fields. Any frontend components without data model binding could have values mapped to a shadow field.
For repeating groups, the values could be stored as a key/value pair where the key is a string and the value is an array.

Pros

• Very simple for app developers to set up
• Allows for rapid prototyping of apps with form before frontend is built

Cons

• No strong typing for the fields
• Need to set up new API endpoints
• Need to determine where this data should be stored
• Need to determine what to do with the data once the process is complete
• @olemartinorg: No inherent support for repeating groups
• Need to make changes to app frontend

Conclusion

We will go with alternative 1 as the first solution. This covers the requirements, and solves the problem in the same way as Altinn 2. Other pros are that it will be easy to implement, allowing us to spend our time on more pressing areas. It is important to note that by selecting alternative 1, we do not restrict ourselves to only this solution, and could f.ex. implement alternative 3 as a solution in parallel in the future. Answering the open questions for this analysis:

• What is supported in Altinn 2?
  • Shadow field data is stored with the form data, and deleted on submit.
• Are there needs/requirements outside of what is supported in A2?
  • Storing this data as form data covers the requirements for "basic functionality". If other needs arise we should consider alternative 3 as a parallel solution.
• Where should such data be stored?
  • Data will be stored together with the form data, and stripped away onProcessEnd.
• Do we need to persist the data once the instance is completed?
  • We will not persist the data after the instance is completed. Again, if there for some reason comes up a need for this, we should consider alternative 3.
• Should this type of data be bound to a specific task, or available across the entire process?
  • The data will be stored in a data element connected to a specific task, but it will be possible to read from this in other tasks in the process.