ImageProcessor to intercept the UIImage #2
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
This PR introduces the concept of an
ImageProcessor
to AsyncImage.Currently, the
UIImage
loaded by theImageLoader
is directly converted into a SwiftUIImage
before it is leaves theImageProcessor.loadImage()
, thus making it unavailable to the app implementing theAsyncImage
. Therefore, no changes to the image itself can be made.The
ImageProcessor
is a protocol specifying only one function:func process(image: UIImage) -> UIImage
. If a class implementing this protocol is supplied to theAsyncImage
, this function will be called before theUIImage
is converted into a SwiftUIImage
. In this function one has unrestricted access to theUIImage
.Because the
ImageProcessor
processes the image after it has been added to the cache, only the original version of the image is saved to the cache. This means that otherAsyncImage
instances that do not use the sameImageProcessor
can get the original image, whileAsyncImage
instances that use the sameImageProcessor
do not amplify their changes to the same image over time.Also, I've removed the unnecessary debug print statement from the code.
Discussion
While this prevents the
AsyncImage
from being a drop-in replacement for Apple's official implementation when replacing thisAsyncImage
with Apple's due to the additional initializer parameter, theImageProcessor
is completely optional and can be omitted from the initializer call of not needed.However, I argue that the flexibility achieved by having access to the
UIImage
far outweighs this drawback, and may also provide a differentiator agains Apple'sAsyncImage
.