Workshop: simplify dynamics/rules/tracks

[lorang92]

Description

The current implementation for dynamics/rules +tracks is tedious and requires the app developer to modify several files and duplicate logic both frontend and backend. This does not scale.

Some of the concerns from Finanstilsynet has been documented in a github gist: https://gist.github.com/simendsjo/37581b29c8ad62ed83934ac41cff58a5

A proposed solution here has been to use a DSL (domain specific language) that will simplify these statements and making it reusable both backend and frontend.

This issue is used to document thoughts and questions that arise during the workshop.

Painpoints

• Duplication of logic frontend + backend
• Logic spread out over several files + locations
• Data in hidden fields are sent with the xml data
• validation - is the field hidden?

Considerations

• Intellisense on dynamic statements
• Overview of dynamics

In scope

• Find suitable syntax (or reuse) that can solve our needs for dynamics/calculation independent of javascript + c#
  • Can be used for trakcs (at page level)
• Document architectural choice
• Identify challenges that needs to be solved
• POC

Out of scope

Additional Information

A possible candidate that has been mentioned is DMN FEEL (friendly enough expression language). This has libraries to evaluate such statements, a simple example is js-feel (no longer considered a viable option)

Solution

"hidden": {
  "function": "equals",
  "args": [
    {
      "dataModel": "MyModel.Group.Field"
    },
    {
      "component": "my-input-field"
    }
  ]
}

Nice-to-have/simple DSL variant:

"hidden": {
  "expr": "dataModel(MyModel.Group.Field) == component(my-input-field)"
}

See the example above. Minor changes may come.

Functions we must support:

• greater than
• equals
• lesser than
• ... TODO: add relevant functions

Relevant default functions we support must be supported in both c# and javascript. This enables us to generate lists of hidden fields for validation + remove "dead" form data that is hidden when the user submits.

This will enable us to both run dynamics trivially on the frontend + backend to solve the mentioned painpoints, as well as solving the maintainability hell illustrated in the picture below:

For the app developer, this will now look something like this (things might change):

This is also easier to both read and understand, and you have a clear understanding of when this field is hidden just by looking at one single file.

For more complex functions not covered by our default functions we can also reuse the concept of shadowFields that are being worked on in the other workshop track. Simply do the necessary logic backend and store if a given field should be hidden as a shadow field. Then setup hidden with a simple boolean check against the given shadow field.

Questions for the way forward

• Backward compability for the existing features?
  • CalculatePageOrder
  • Current dynamics
  • Setting up dynamics the old way in studio
• New major version?

Thoughts

• When should dynamics for layouts run?
• Alt 1: at the same time as components, then update layoutOrder and hidden fields
• Alt 2: components are run as is, but layouts have their own trigger (maybe at nextPage?)
  • Seems to cause issues, we need to have a single point of truth in our global state for prev for instance.

Seems to be just easier to run these at the same time and update states accordingly.

Tasks

• App frontend
  • Oppsett for implemetasjoner av nye basis-funksjoner (starte med en?)
  • Støtte for dynamikk på komponent-nivå @olemartinorg
  • Støtte for dynamikk på side-nivå @lorang92
• App template
  • Oppsett for implemetasjoner av nye basis-funksjoner (starte med en?)
  • Stripping av form data basert på skjulte felter under innsending
  • Tilgang på liste over hva som er skjult (eventuelt vist?) under validering
• Studio
  • Oppsett av nye regler
• Docs
  • Dokumentere ny måte å sette opp dynamikk
  • Opprydning
• Json Schema
  • Legge til json schema definisjon for nytt dynamikk oppsettt i formlayout

[olemartinorg]

Closing now that #355 has been implemented