Proposal: UI configuration

[pkalita-lbl]

This is just a starting point of a discussion and not necessarily fully thought-out yet.

The basic idea is that a schema (LinkML or otherwise) generally can't capture everything about how a tool to collect data adhering to that schema should look or behave. Obviously the schema can inform some sensible defaults (i.e. provide a dropdown menu when a value must be chosen from an enumeration) but it can't capture things like "suggest terms retrieved from this arbitrary endpoint". Or "this field should be omitted from the entry UI because it will be populated by a separate process" (see https://github.com/cidgoh/DataHarmonizer/issues/337). For use cases like these that are common enough, it would be nice for data-harmonizer clients to not have to write a lot of custom code and instead simply provide some configuration.

The changes here represent a very basic sketch of what a UI configuration approach might look like. A data-harmonizer application (i.e. web/index.js) provides a UI configuration object to the DataHarmonizer constructor (an application could even store this configuration in a standalone JSON file). The DataHarmonizer class is responsible for interpreting this configuration and applying the correct settings internally. The specific example implemented here is directing the DataHarmonizer instance to use an OLS-based autocomplete for a particular field.

It's not implemented in this proof-of-concept, but you could also imagine a UI config like:

{
  "fields": {
    "internal_id": {
      "hidden": true
    },
    "look_but_dont_touch": {
      "readonly": true
    }
  }
}

I could also imagine non-field-specific configuration going outside of the "fields" key (e.g. https://github.com/cidgoh/DataHarmonizer/issues/334):

{
  "numFrozenColumns": 2
  "fields": {
    ...
  }
}

Again, this is just a conversation starter. I'd be interested to know if this might address (or not) other cases.

cc: @ddooley