First Take w/ Github Image

[brh55]

Decided to take a first stab of enhancing pre-existing work in the PR #6. This PR mainly is using this repository as a way to provide image to directly referenced (against ToS? not sure 👯‍♂️ ), as well as additional minor improvements. Feel free to revise / update anywhere accordingly

Changes Include:

• Optimizes build to skip pre-existing images
• Adds a compressed 120 x 120 Icon version of the full image
• References raw GitHub image and icon locations within JSON (This can be kept / remove up to you)
• Restructures the cryptocurrencies.json file to accommodate for changes (open to changing property names)
• Removes the list of currencies within the readme (was getting a bit too long when landing on the repository), but now moves this over to list.md, which now contains the icon images

Let me know what you think @radiovisual

[radiovisual]

Looks good to me. The only thought I have is that maybe we offer two JSON files, one with the image data, and one without? This repo is about getting a list of cryptocurrencies, the images are just a bonus, but I think some use cases won't require the extra bloat from the image urls. What do you think

[radiovisual]

maybe we need to add a --force flag to the build then, because this checks for an existing image, but sometimes the icons change, and we will want a way to grab the updated images. We could get fancy with checksums, but it might be overkill.

[brh55]

Yes that's what I was thinking, a force flag should be beneficial.

[brh55]

Looks good to me. The only thought I have is that maybe we offer two JSON files, one with the image data, and one without? This repo is about getting a list of cryptocurrencies, the images are just a bonus, but I think some use cases won't require the extra bloat from the image urls. What do you think

Agreed, let's go ahead and do that. How about the API implementation (.BTC vs .BTC.name)?

[radiovisual]

How about the API implementation (.BTC vs .BTC.name)?

.BTC 👍

[brh55]

Suggestions for the name of 2nd json file with images?

[radiovisual]

Suggestions for the name of 2nd json file with images?

Ideas:

• currencies-logos.json
• currencies-meta.json (future-proofing, but semantic)
• currencies-plus.json (future-proofing, but semantic)

[brh55]

@radiovisual Updated per PR comments.

1. Force flag (--force, force, -f, -force) will skip optimization and download all files
   • npm run build will be entire build process
   • npm run fast-build will be an optimized build process
2. cryptocurrencies.json and API will remain intact
3. cryptocurrencies-meta.json will be available for download

[radiovisual]

Looks good to me. My main issue is with the GitHub hosting. If anyone is going to use this in a real application they would want the images delivered by a cdn, and to be hosted in a way that is scalable and reliable. So maybe we add a note (disclaimer) that the GitHub hosting is for reference only, but give them a build command to specify where the images should be saved, and generate their own custom JSON file with the updated paths, then we can recommend that they maintain their own build process in their own apps This would free us from having to maintain a database of these images (that would break someone's app every time we updated the list of images 😆 ), but give users the flexibility to do what they want with the images without the right to yell at us. 🤣

[brh55]

@radiovisual That's an excellent point. How about we include a build to generate a meta file for the images stored locally, and the current meta (will need to rename) file used only for the purpose of this repository's list.md for visual reference purposes?

[radiovisual]

How about we include a build to generate a meta file for the images stored locally, and the current meta (will need to rename) file used only for the purpose of this repository's list.md for visual reference purposes?

I like the idea of letting them generate their own metafile with references to the images, which forces them to maintain the images and the list on their own, and in this case, we don't even need to generate the meta JSON file at all, because if all we are doing is hosting the images to show in the list.md file, then we only need a file path for that in the .md file, which means we don't need to create a JSON file. So I vote for:

1. Remove the META JSON file completely
2. Use the build process to gather the images to the images dir
3. Automatically add the image path to the list.md file
4. Add a disclaimer to the list.md file that the images should be used for reference only, and can't be trusted as reliable links to images for their own apps as the icons can and will change without notice, and....
5. Instruct users how to use the custom build process that that will save the images locally and generate a custom META JSON file for them to use in their own apps (in the README.md and LIST.md files)
6. Expose the configuration flags to the build cli letting users generate the icons and custom meta JSON.

This way, they only thing we officially support is the somewhat up-to-date list of cryptocurrencies, with the build tool that lets users gain easy access to the image icons to use however they see fit...and we are pretty clear every step of the way that we aren't trying to maintain a versioned icon reference for anyone...since that would quickly become a nightmare to maintain.