Centralizing data conversion and storage

[PaulBredl]

The modularity of our code could be improved.
Especially the AceEditor and the PropertiesPanel are quite big files.

Issues

• The PropertiesPanel is crowded with data operations, such as add and item, rename property, ...
  We should implement a central DataManager that is responsible for those operations.
• Currently, the ace editor is responsible for parsing and stringifying data.
  But other components also should have access to the raw, unparsed data, e.g. the toolbar.
  We should move the data convertion and simultaniously make it easier to extend the tool with other data formats.

Proposed design

The following components should be added/adapted:

Central data format registry

We implement a registry for all data formats that provides tha following interface:

• getFormat(name: string): DataFormat: Returns a registered data format
• registerFormat(name: string, format: DataFormat: Registeres a new data format

Internally, this registry would use a simple Map

DataFormat interface

• dataConverter(): DataConverter returns the data converter (see below), mandatory,
• pathCursorPositionLink(): PathCursorPositionLink() | null returns the linkage logic to map from a path to a cursor position and vice versa. Can be ommited, but will make the tool less effective with that format.

DataConverter

Parse and stringify data, with utility methods.
useDataConverter(): Static accessor to the converter of the current data format.

PathCursorPositionLink

See current ConfigManipulator for methods (except parsing and stringifying)
usePathCursorPositionLink() Static accessor to the link of the current data format

DataStore

The data store should be modified in the followings ways:

• Store a pair of data and schema data (raw schema data, not the optimized schema) for each (user data, user schema, user settings (potentially)
• Only use shallowRef
• Use of a plain object instead of a pinia store:
  • pinia features are not really required here
  • pinia stores convert refs to objects, and thereby make it intransparent that the data is acutally a ref. We also had some issues in the past where refs from pinia would not trigger watches as expected

DataLink

The data link interface will basically be the tripple (data, data as raw string, schema of data), with the following properties:

• the (shallow) refs to schema and data are parsed as constructor parameters
• the string representation is stored in this class
• the string representation and the data ref are bidirectionally linked, updating one will update the other.

SchemaPreprocessor

The schema preprocessor should become a composable or a class that is resposible for preprocessing raw schema data.
It should expose:

• the preprocessed schema
• the GUI optimized schema (after the lazy preprocessing steps) -> JsonSchema class could be renamed to GuiOptimizedJsonSchema

DataManager (or potentially DataAndSchemaManager)

The class that will be responsible for accessing and modifying the data in the components of the tool.
Dependencies:

• A DataLink. This will be switched when changing the page / current mode
• A basePath (?), currently known as currentPath. Will make working with relative paths ("zooming in") easier. => Alternatively, the callees are responsible for determining the absolute path.
• The schemaPreprocesssor to get the GUI optimized schema

Responsiblities:

• read/write data at a certain path
• insert new properties and items
• delete data at a certain path
• calculate the effective schema (at a certain path)
• ...

The session store will be responsible for providing the correct data manager for the current page.

This class could be used as a prop in components to reduce dependecies to the session store (optional).

Todos

• Implement the corresponding components and use them, potential split:
  • First FormatRegistry to DataLink
  • Then SchemaPreprocessor
  • Then DataManager
• Write tests for the modular components
• Use them and replace the old implementation