Ability to store data in project settings

Help & Support
,
#1

There are probably many reasons not to allow this, but I’m wondering if there is any safe way to store custom json data in the project settings using the editor api?

My use case for this is it would be really helpful if our Package Manager chrome extension could store and access data such as package names plus configuration info on a per project basis. Currently we are storing this data in a standalone json file in the asset registry, but we need to add additional logic to track the file (renaming/path change etc) and there’s a few edge cases where it breaks down.

Ideally we could have a slot in the project settings to store this data which would then sync with everyone on the team. The data we’d want to store would be something along the following lines:

{
  "dependencies": {
   "somePackageName": "0.1.2"
  },
 "config": {}
}

Some options;

  1. Allow an dedicated field where arbitrary json data can be stored?
  2. Probably safer; add a field to the project settings that points to an asset ID. Similar to the Area light LUTS etc. This would mean we can keep the config file in the asset registry, the user manually selects it, and it doesn’t pollute the project settings with arbitrary data.

Any thoughts would helpful @jpaulo

2 Likes
#2

Hey! Interesting use-case you have there, and I can definitely see how this can be useful. My first impression on this is that indeed option #2 is safer, and if we were to implement option #1 we would need to add constraints (such as in total size limit in bytes, limit supported types, etc).

While we discuss internally what can be done about this, can you elaborate a bit more on the “edge cases that break down” your current approach of using a JSON file in the Asset Registry? Perhaps we might find a way of improving that workflow without needing to mess with Project Settings.

#3

For sure. As a quick overview; the extension has a UI Panel that operates on a json file within the registry. It displays information stored in the file and and allows users to update it by adding and removing packages.

image
The above image is showing data stored in the json file

As we don’t have a fixed reference to the file ahead of time we have to search for it using the following assumptions when the editor loads or when a new file is created

1. File must be a json file
2. File must be in the root of the registry
3. File must be named 'package.json’

Any file that meets these requirements is valid and we assume we can store and retrieve data from it. If no file is found we disable the extension which gives developers the abilty to opt-in/out

However this test isn’t totally reliable as assets can actually share names, for example you can have multiple ‘package.json’ files in the root which would all pass the above test. A more reliable identifier would be the asset ID which is unique across the registry.

An example where this might cause issues is where two or more developers working on the same project where they both individually create a package.json and add packages to it, potentially making two files that need to be merged.

3 Likes