Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

ImageRequest userInfo dictionary Any type for value allows unsupported types for imageIdKey #772

Open
sean-escendant opened this issue Mar 17, 2024 · 2 comments
Labels
improvement Non-functional change that improves existing functionality

Comments

@sean-escendant
Copy link

sean-escendant commented Mar 17, 2024

My project is using signed URLs for images and Nuke 12.4. I followed the documentation to use a custom image id key. Initially I had passed a URL, with query parameters stripped, as the custom key but testing showed that the cache wasn't working as expected. Only when I changed the key to a String, as in the documentation example, it started working as expected.

It seems some trade offs were made in the API design from Nuke 9 to 10 which introduced this, hopefully you can find a way to keep the API strongly typed otherwise a clear notice in the documentation as to what are the supported types for imageIdKey.

@kean
Copy link
Owner

kean commented Mar 23, 2024

Hey, @sean-escendant. Thanks for raising this. I think it's a valid concern, and this change also had other implications: a slight impact on performance and potentially higher memory use if one of the user info keys is used.

How would you suggest approaching it?

@kean
Copy link
Owner

kean commented Mar 24, 2024

I'm planning to work on version 13.0 soon, and it would be a good time to introduce any breaking changes if needed.

@kean kean added the improvement Non-functional change that improves existing functionality label Apr 15, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
improvement Non-functional change that improves existing functionality
Projects
None yet
Development

No branches or pull requests

2 participants