Server-based vs recursive fields

[nbenn]

We currently have two approaches in place for "non-atomic" fields, i.e. fields which do not directly map to a single input component:

• "recursive" fields such as list_field and variable_field
• server-based fields such as keyvalue_field

and the goal is to decide on a single approach and stick with it.

Recursive fields

An issue with the current code-base in how we use the list field for the filter_block has made the list field implementation (especially the value<-() replacement function) overly complex and this alone might be reason to abandon the approach all-together. In that sense, this should be addressed in order to keep the "recursive"-field approach in contention.

The issue stems from how the list sub-fields are passed not as static values in new_filter_block(), but as dynamic function which returns a list of fields. Every execution of this function will return a list of fields with correct length and types, but each re-initialized with default arguments, thereby overriding whatever the user has already inputed. This necessitates holding on to the current values separately and upon every execution, re-setting the values of the re-initialized fields (as well as handling edge-cases where a field has been removed, etc.). What is available currently works in basic scenarios but will fail for things like field re-ordering.

Approaches to improve the list field:

• Representation of sub-field type and state could be represented in separate components, to allow for a function determining some aspect, while not re-setting the entire sub-field.
• Such a separation is already available from a variable_field, so perhaps the mistake is in not using a list of variable fields for the filter block.
• The current field state(s) could be made available to the update-function, putting the block implementer in charge of not re-setting.

With the current list-field use in the filter block we have an example for function-driven use. How would this behave in other scenarios? If we wanted to add some sort of (+)-functionality, how would that construct a sub-field? How is e.g. field type resolved?

Server-based fields

What are actual issues with the server approach?