Description
A layout can define some components as conditionally "hidden" with an expression. If the user enters some information in a component before changing (a presumably earlier) answer, so that a components "hidden" expression changes value, it usually makes sense to remove the associated data. Because users might explore the logic of the app, the data needs to show up if he reverts the choice that triggered the condition.
Removal of data is done in 3 cases
appLogic.RemoveHiddenData adds a step when finishing a task to remove all hidden fields from the data model(s)
- Validators that implement
ShouldRunAfterRemovingHiddenData => true will not see hidden fields
- DataProcessors that uses
dataMutator.GetCleanDataAccessor().GetFormData<Model>()
Sometimes we want to hide components in the frontend, without actually removing the data. There are multiple ways to implement this, and we need to make the right choice.
There are 4 distinct outcomes that are possible
- Field is not hidden and not removed
- Field is hidden and removed
- Field is hidden but not removed
- Field is not hidden but removed (maybe not relevant?)
As we have 1 boolean expression "hidden", it makes sense to expand to 4 options by adding another boolean option.
1. New expression property "remove" on component
The most obvious solution would be to add a new expression "remove", but for backwards compatibility it needs to default to the current value of "hidden" if undefined or null.
Is it obvious what "remove" would mean?
2. New property "removeWhenHidden" on component
This does not support outcome 4, and it is slightly awkward that the default will depend on appSettings.RemoveHiddenData, so we have a 3 way boolean
It has a few nice properties.
- Mostly not needed
- Adds a path to remove the global setting
RemoveHiddenData, because we can set removeWhenHidden to false on all fields in a upgrade script.
3. New property "visuallyHidden" on component
For visual representations (frontend) it is evaluated and or'ed with "hidden", but when removing data it is ignored.
Other alternatives (better naming)
???
Description
A layout can define some components as conditionally
"hidden"with an expression. If the user enters some information in a component before changing (a presumably earlier) answer, so that a components"hidden"expression changes value, it usually makes sense to remove the associated data. Because users might explore the logic of the app, the data needs to show up if he reverts the choice that triggered the condition.Removal of data is done in 3 cases
appLogic.RemoveHiddenDataadds a step when finishing a task to remove all hidden fields from the data model(s)ShouldRunAfterRemovingHiddenData => truewill not see hidden fieldsdataMutator.GetCleanDataAccessor().GetFormData<Model>()Sometimes we want to hide components in the frontend, without actually removing the data. There are multiple ways to implement this, and we need to make the right choice.
There are 4 distinct outcomes that are possible
As we have 1 boolean expression
"hidden", it makes sense to expand to 4 options by adding another boolean option.1. New expression property
"remove"on componentThe most obvious solution would be to add a new expression
"remove", but for backwards compatibility it needs to default to the current value of"hidden"if undefined or null.Is it obvious what
"remove"would mean?2. New property
"removeWhenHidden"on componentThis does not support outcome 4, and it is slightly awkward that the default will depend on
appSettings.RemoveHiddenData, so we have a 3 way booleanIt has a few nice properties.
RemoveHiddenData, because we can setremoveWhenHiddento false on all fields in a upgrade script.3. New property
"visuallyHidden"on componentFor visual representations (frontend) it is evaluated and or'ed with
"hidden", but when removing data it is ignored.Other alternatives (better naming)
???