Generalization of the project information structure about gltf-project-explorer HOT 2 OPEN

A first pass for this generalization has been drafted in #154

Based on the state that is described there, here are a few more specific questions (even though some of them have been mentioned above already)

• Should the value type always be string[]?
  There could be value types that are just a single string, or a number, or even a number[] array. Iff there should be any functionality that is "type specific" in this regard, it might be necessary to create a more sophisticated solution. Think about a property like gitHubStars : number, and an option to sort by this, or even computing statistics like min/max/avg for some property...
• Where and how to define the properties?
  Currently, they are hard-coded as a set of strings, called ProjectProperties.
• How to define the usage of the properties?
  Specifically: It is currently possible to filter by some of these properties, but not by all of them. This is also hard-coded right now, via ProjectFilterProperties.
• Should properties always be 'flat', or should they be allowed to be 'structured types'?
  Something like a 'date' could be modeled as three properties, year,month,day, or as a class Date { year, month, day }.
• How to model relations with this structure?
• How to map this to a persistence layer?

Many of these questions are related to the idea of a "schema-like" description of the project structure. The complexity of the actual solution for that will depend on the answers to the questions above. I think that we could get pretty far with a simple schema definition. But while fleshing that out, the topic of persistence should be kept in mind. (For example: We could probably add type information to such a schema. But how will that type information be reflected in the database?). Related to that: I stumbled over https://github.com/typeorm/typeorm , which may be worth a closer look. But I assume that we'd try to keep the IProjectInfo structure for the UI (and simple client-side operations), and try to keep that separate from the persistence layer as far as reasonably possible.

@weegeekps Maybe you want to add your thoughts, or have a short look at the PR (even though it is an early draft)

from gltf-project-explorer.

I noticed that the generalization has not been applied at

from gltf-project-explorer.