Changes to JSON structure

[adamrusted]

As highlighted in #9358 the main JSON is getting pretty massive at this point.
I'm starting this issue to try and gather ideas on how we might mitigate that, at least from a development perspective.

My initial (somewhat selfish) idea was to split out into a JSON file per letter of the alphabet. This would make the letter-by-letter review approach of #9072 a lot easier - but I'm aware that might not be the best solution possible.

Another idea would be to have a folder structure along the lines of <brand>/<product line>/<product> - which would mean that for example:
At the brand level, we could have general guidance that applies to all 'Microsoft' or 'Apache' icons.
You then go further down into the product line - so in the Microsoft example, Office, Power Platform, or Azure - or with Amazon you can have Amazon brands, and AWS as a separate sub-folder.
Finally, you get to the product level, and this would simply be a single JSON per entry, so in the above example - Word, Excel, etc.
Anything defined further into the folder structure would override what is applied at a higher level (for example, if Word had a specific source / guidelines link different to the Microsoft, or even Office file, it would override when generating the JSON.

Unsure how either of these would play out with regards to bundling, but I'm assuming you could just add a 'build' step to generate one giant JSON based on everything found in the folder structure.

Would be great to get some discussion going on this issue - and see what ideas we can come up with!

[mondeja]

My initial proposal is to split by letter as you proposed and remove the icons property from the new files, then create a build script to distribute the JSON file as currently is, so we don't make breaking changes. And, in a breaking version, just remove the icons property from the distributed JSON file.

I feel that this change is to facilitate icon additions and reviews, because if we are talking about file size, the icons property removal should be the most obvious priority.

The product/subproduct/subsubsubsubs.... folders approach seems to me really confusing.

[adamrusted]

so structure would instead be:
data/a/icons.json, data/b/icons.json
with an array of objects, which we would compile into a single file at build-time?

[mondeja]

I was thinking on _data/a.json, _data/b.json... with an array of objects which we would compile into a single file at build-time.

[quantumflo]

I think _data/simple-icons/a.json, _data/simple-icons/b.json. Should we have a intermediary directory and then have json splitting inside it?

[LitoMore]

I prefer to create a simple web app for viewing the icon data.

The a.json, b.json confused me about these names: .ENV, /e/, 1001Tracklists.

Imagine we have 36 JSON files from 0 to 9 and from a to z.

[adamrusted]

I would do as I've done with the reviews, and count all symbols and numbers as one entry. Comparatively, there are a lot fewer even combining them all.

[PeterShaggyNoble]

One thing we could do to reduce the file size, at least, would be to remove all the www subdomains from all the URLs and add that to our linter.

We'd need to do a HEAD request for each one, though, to ensure it still returns a 200 OK status. I can easily throw together a script to run through the existing entries and do all that, but is our linting process capable of making external requests?

[adamrusted]

The 'ourlint' is just a JS File - so using the native fetch API shouldn't be an issue

[PeterShaggyNoble]

The 'ourlint' is just a JS File - so using the native fetch API shouldn't be an issue

CORS policies could be, though.