👋 Welcome to the community!
Thank you for opening your first issue. We appreciate your contribution and will review it as soon as possible.
Feel free to ask questions, share ideas, or provide any additional details! We're here to help. 😄

It would be awesome to have the ability to provide a custom cacheKey that would fall back to use the URI if none provided.

Our use-case is that some of the images are already available locally, prior to being uploaded to a remote distribution endpoint.

With a custom cacheKey we could take advantage of the local images by setting something like like cacheKey: ${image.id}-${updatedAt} with the local image path. Later if it uses the remote URL it would already have the image cached based on the custom cacheKey and not need to re-cache the same image.

@kevinranks, thanks for your suggestion.

I'm summarising my understanding so that we can brainstorm it internally and come up with a solution.

You expect an additional prop cacheKey to avoid caching redundant images. Currently, path based caching can lead to caching the same image twice specifically in scenarios where the image was loaded from local and later retrieved from network.

Have I understood it correctly?

It would be awesome to have the ability to provide a custom cacheKey that would fall back to use the URI if none provided.
Our use-case is that some of the images are already available locally, prior to being uploaded to a remote distribution endpoint.
With a custom cacheKey we could take advantage of the local images by setting something like like cacheKey: ${image.id}-${updatedAt} with the local image path. Later if it uses the remote URL it would already have the image cached based on the custom cacheKey and not need to re-cache the same image.

@kevinranks, thanks for your suggestion.

I'm summarising my understanding so that we can brainstorm it internally and come up with a solution.

You expect an additional prop cacheKey to avoid caching redundant images. Currently, path based caching can lead to caching the same image twice specifically in scenarios where the image was loaded from local and later retrieved from network.

Have I understood it correctly?

Yes exactly. In an app that users upload many images to a remote server, it makes sense to be able to utilize the local copy of that image prior to uploading it remotely. It's my understanding that right now the internal cache key is based off of the URL. By offering the ability to override that it gives developers a lot more control over the cache. For example, being able to reference a local path for an image and then later use the remote URL, and as long as the cacheKey is the same for both you can show the local (temp) image while the image is being uploaded remotely. Once the upload is complete the source URI can change to the remote URL, but if the cacheKey is the same, it would not need to download the image again. All without any additional components or special logic.

Thanks for forking this package and maintaining it!

@kevinranks, it definitely makes sense. We will brainstorm internally and come up with a solution. Also, if you're interested in contributing to this repo, would suggest you to join our discord channel - https://discord.gg/BNHhcpYD