Official web-based GUI client for evitaDB e-commerce database. It is built to help developers who use evitaDB with exploring and debugging their domain structure and data. Besides standard query executing, it also supports multiple no-code tools to quickly navigate through domain structure, docs and data without needing to write any queries.
Right now the data grid property selector is constructed rather manually because initially there were only two layers (sections and direct properties). Now we have already 3 layers (each property can have child properties). Although we don't expect more than 3 layers in future as even the third layer is rather difficult to render flattened, even the 3 layer layout is difficult to manage manually.
We could transform current data structures to a single tree of different nodes (section nodes, property nodes, ...), the entire rendering and user input handling could be largely automated. We could use the subtrees to toggle entire sections, filter nodes with references to parents (this way we could maybe hide entire sections if there are no filtered properties in them. We could also have property nodes directly in root next to the section nodes (this would be useful for prices as they don't have any children and a price section would be unnecessary for a single price property).
The tree structure could look something like this:
Right now the data grid property selector is constructed rather manually because initially there were only two layers (sections and direct properties). Now we have already 3 layers (each property can have child properties). Although we don't expect more than 3 layers in future as even the third layer is rather difficult to render flattened, even the 3 layer layout is difficult to manage manually.
We could transform current data structures to a single tree of different nodes (section nodes, property nodes, ...), the entire rendering and user input handling could be largely automated. We could use the subtrees to toggle entire sections, filter nodes with references to parents (this way we could maybe hide entire sections if there are no filtered properties in them. We could also have property nodes directly in root next to the section nodes (this would be useful for prices as they don't have any children and a price section would be unnecessary for a single price property).
The tree structure could look something like this:
This tree would be computed at the component initialization from input props and would be used to manager rendered selector.