Looks OK on UIImageView that category support.

But...Maybe need a way to workaround UIButton (Called, multi-state-image-view)...Which will cause issue in current sd_imageURL API, because it does not associated to a State. Actually I try to avoid touching that property

I write a implementation 2 years ago but has no response, which is ugly and hacky so I close it and forgot that... #2790

Looks OK on UIImageView that category support.

But...Maybe need a way to workaround UIButton (Called, multi-state-image-view)...Which will cause issue in current sd_imageURL API, because it does not associated to a State. Actually I try to avoid touching that property

I write a implementation 2 years ago but has no response, which is ugly and hacky so I close it and forgot that... #2790

oh @dreampiggy, thanks for your review and let me try to understand what is your point, do you mean the view who can be set multiple images, when we try to load images for different state at the same time, in current sd_internalSetImageWithURL function, the multiple image loading operation will canceled each other, this is what you want to fix right?

this is what you want to fix right?

I don't want to fix this, but if user use UIButton, your new code will cause More problems for them than previous, make things worse (It's bad enough currently).

But I don't think it's your duty to fix this bad design about UIButton in this PR. Maybe it still need me to re-open #2790, and then you don't touch sd_imageURL, instead, touch that new API sd_imageLoadStateForKey:

A better idea is to mark some warning in UIButton+WebCache, or UIImageView+Highlighted, those who has possible multi-state-image-view behavior

@dreampiggy

1. I don't want to fix this, but if user use UIButton, your new code will cause More problems for them than previous, make things worse (It's bad enough currently).

   • I don't understand why the new code will cause more problems? I think it should be same as now. can you explain more?

2. and I also review the code for the multi-state-image-view case.

• I think the maybe SDWebImageContext could resolve it.
• because current operation's management is base on NSString *validOperationKey = context[SDWebImageContextSetImageOperationKey]; actually user can customize the key for each status, so if we want make it more convenient for usage, we could add some default customize key for UIButton+WebCache, or UIImageView+Highlighted. right?

actually user can customize the key for each status

No, this is not designed as public API, only for SD's third-party integration (like that FirebaseStorageUI integration) to use.

I don't understand why the new code will cause more problems? I think it should be same as now. can you explain more?

Previously, this:

1. UIButton setImageWithURL:url1 forState:normal
2. UIButton setImageWithURL:url1 forState:touchUpInside
   Will still work and set the images into that UIButon's 2 states

However, after you changes, since UIButton.sd_imageURL is memorized

Will cause that UIButton's touchUpInside no longer set any image, and will cause blank when user touch.

It's already buggy, but this new behavior changes make more buggy...

But this is SDWebImage's old design issue, not your duty. If you want to merge, maybe I have to pick up #2790 and merge it before your PR merged in

You can guess what I means, that UIView.sd_imageURL is Deprecated and buggy API which I don't recommended anyone to use, for now

Until I provide new API like UIView sd_imageURLWithKey:

actually user can customize the key for each status

No, this is not designed as public API, only for SD's third-party integration (like that FirebaseStorageUI integration) to use.
oh this is what I mean.

        button.sd_setImage(with: URL(string: "https://xx"),
                                  for: .normal,
                                  placeholderImage: nil,
                                  context: [SDWebImageContextOption.setImageOperationKey : "normal"],
                                  progress: nil, completed: nil)
        button.sd_setImage(with: URL(string: "https://xx"),
                                  for: .highlighted,
                                  placeholderImage: nil,
                                  context: [SDWebImageContextOption.setImageOperationKey : "highlighted"],
                                  progress: nil, completed: nil)

it could help to avoid image loading canceled right?
and of course like your sample code, my code could impact original logic.

That setImageKey is used to define Which property you want your image to set on current view. Which is actually a Swift KeyPath: https://developer.apple.com/documentation/swift/keypath

One Image Request from UI level, can bind to 3 states:

1. Image View instance (who call this ?)
2. Image URl (what to load ?)
3. Image Set Image Key (which property to set ? Like UIImageView has 2 properties, highlightedImage and image, can represent Image)

Means, it can be a KeyPath: \.image, \.highlitedImage, \.normalState \.touchUpInsideState

It's not URL or Cache Key, which is data-source. It's a UI state management problem (I think SD is not a UI framework, but users think...They put the problem to us)

This is history bad design for multi-state-image-view.

So, you shoud not rely on Anything not bind with setImageKey to do cancel or skip load. Because cancel is a state change, and will break the state management if not processed correctly.

If I provide the API like currentView.sd_imageURLForSetImageKey:key, then you can say that current request can be cancelled safely because <view, url, keypath> are all same, they are Actually same image pipeline for state management

In SD 6.0, I decide to provide new API for Swift user to always pass KeyPath, defaults to \UIImageView.image for UIImageView.sd.setImage(with: url), no longer strange design like UIImageView.sd.setHighlitedImage(with: url)

@mTz0206 See #3576

You need the new API from that and then merge-in.

Any update ? Do we still need this PR ?

I suggest to add a new option (to not cancel current loaded image request)

Any update ? Do we still need this PR ?

I suggest to add a new option (to not cancel current loaded image request)

thanks, I will review this > See #3576
and try it this weekend, thank you still remember this.

I can provide a draft PR for you actually. Check if this match your feature request.

I can provide a draft PR for you actually. Check if this match your feature request.

oh really？ thank for that.

See #3592's test case about the new behavior. I guess this is enough for you ?

By the way, I think in the more complicated scenario, you can directly call SDWebImageManager instead of use the built-in logic from UIView+WebCache.m