UI support for unsupported driver values

[lukashornych]

In #94, the evitaDB driver concept were introduced to support different versions of evitaDB server versions within single evitaLab version. For this, an internal model representing evitaDB's model were introduced with Value class representing a evitaDB model value that may not be supported by chosen driver version (server version). Its primary purpose is to disable parts of the UI for which the used evitaDB server version has no data. The UI must have some way to tell the user that certain part is not supported by the chosen driver.

Currently, the unsupported values are handled as if they were empty but supported, which is temporary simple solution but not desired. This issue will change that.

[lukashornych]

On top of the Value class, we could introduces listing of supported features by a driver. Then the UI elements would check if a feature is supported or not and display either the element or something to indicate that the element is not supported by the driver.

There would a set of features or supported data by the evitaLab, like so:

enum SupportedData {
  CatalogSchema = 'catalogSchema',
  CatalogSchema_ProductSchema = 'catalogSchema.productSchema'
  CatalogSchema_ProductSchema_AttributeSchema = 'catalogSchema.productSchema.attributeSchema'
  CatalogSchema_ProductSchema_AttributeSchema_Description = 'catalogSchema.productSchema.attributeSchema.description'
  CatalogSchema_ProductSchema_AttributeSchema_Localized = 'catalogSchema.productSchema.attributeSchema.localized'
}

A driver would then list all data the it can provide (it supports):

class EvitaDBDriver_2024_1 {
  getSupportedData(): SupportedData[] {
    return [
      SupportedData.CatalogSchema_ProductSchema_AttributeSchema_Description,
      SupportedData.CatalogSchema_ProductSchema_AttributeSchema
    ]
  )
}

Then there would be a service for the UI elements to check if the driver supports certain data:

class ConnectionService {
  isDataSupported(connection: Connection, data: SupportedData): boolean {
    return /* ... */
  }
}

This logic would be working in conjunction with the Value class. The Value class would be inside the domain code to provide models and default values, then the UI would get a default or empty value and would check against the list of supported data how it should be rendered.

We will need to discuss it more, this is just a though for now.