search

afterschoolstudio / Depot

Structured data editor built inside VS Code
Apache License 2.0
186 stars 19 forks source link

RFC: Raw JSON Import #47

Open kkukshtel opened 2 years ago

kkukshtel commented 2 years ago

Lots of people have suggested that Depot should support the importing of raw JSON data. This issue is meant to track use cases/needs and what people would expect as the workflow for that use case.

bbugh commented 2 years ago

I'm not sure this is the same topic I mentioned on reddit, but I want Depot to have a separate schema file and data file. Separating the business layout from data - much like a JSON $schema is a separate file, having a items.depot and items.json would be nice. Benefits:

  1. Makes tracking down the history of when a schema changed vs data changed much easier. Presently, you'd have to look through every change to the file to find when a schema changed.
  2. We can do access control on files, for example having a lead engineer review any time a .depot file changes, but changing data just requires a team member review
  3. Raw json is easier to load for the system, and doesn't require loading the paths of a proprietary format. It would be nice if the game didn't need to care how the data was generated.
    • I generally disagree with the premise in the README that says A Depot file contains its data model, making the file itself portable to any other program. I think it makes it less portable than a plain json data would, alongside a depot "schema".
  4. Similarly, raw JSON data is easier to edit in an editor (like EasyCSV) than the deeply nested depot json

I think Depot is awesome and I think this would make it more practical for game development in teams.

kkukshtel commented 2 years ago

This is a slightly different issue that you're bringing up but it's a bit related so I'll address it here.

Given how Depot works inside VS Code, having a multi-file dependency for edit-time authoring isn't really possible without a lot of user burden for config + managing the data (we leverage Code's "custom editor" API, that only operates as a "view" on the single opened file). On top of that, having multiple files to manage runs counter to the ethos of the project, as the goal and aims are to have a single file that represents all of your data.

I think in your use case, if multiple files are an absolute requirement, there's two support paths I see:

  1. On your end, running jq or something similar to transform the Depot data to your desired, deterministic format. I'm currently working on a C# source generator for the schema so we never have to worry about maintaining what is effectively tons of boilerplate. Someone has already built one for Haxe as well.
  2. This was brought up on reddit, but adding in the concept of "exporting" from a Depot file that has a few options for export. That way you could have the core .depot file act as something of a project file, and then just rely on the export formats that you commit to source control or ingest in your target application. Those exports could be what is actually versioned instead on needing to rely on the "project" file changes (though versioning it as well could act as a source of truth).

Let me know what you think of option 2, as it seems like the one most ready at hand.

bbugh commented 2 years ago

Forgot about this and ran into it again cleaning out my abundant GitHub notifications. #2 as an export would be fine. I think the versioning is reversed though, the depot would be versioned and the exported (generated) files would not be tracked. Otherwise the setup could get out of sync with the data. Being able to automate it is really the desire, and you're right a simple jq could work. We can also just read the depot to build a zod or TypeScript types for the imports.