Sure thing! Not my best video; I struggled finding an example that was simple enough. Happy to do more of these if you have better examples of slow code paths you're trying to improve. Perhaps can take from GitHub projects.

Because cells can be reused. Take the case where you scroll really fast through a list. You might reuse the same cell 3 times (for example). Well that’s 3 image fetches that have gone off and will try to replace that cell with 3 different images when you really only want what should really appear in that place. There are better ways to do this that involve a better image system that allows you to cancel image operations before it tries to resize them.

​@@AppleProgramming I stared at it a few more minutes and now I get it! Thanks for responding.

Definitely a series I should expand on.

Not sure how you would get the current index path when you receive the image. You'd have to store that index path value on the cell to check that it is still valid. Perhaps you could try querying the cell at that index path to see if it's still valid and I suppose that would work.

@@AppleProgramming Within the async task (line 65 at time 22:05), I think the indexPath is still in scope. If we capture the indexPath within the task, we should be able to unwrap the cell from self?.collectionView.cellForItem(at: indexPath), and if it exists we can update the image. I might be missing something though -- I haven't played with diffable datasources just yet

@@Seieukos Ya, that could work. Though I'm not sure existence necessarily guarantees that it is different. I would be tempted to say that it should work, but I haven't tried.

ideluxer It’ll get better. Taking forever to process.

I wish you the best in solving your issue. I do offer 1-on-1 help through Patreon if you find you need it.

@@AppleProgramming WHAT IS YOUR INFO THERE I HAVE A PATREON AS WELL

@@AppleProgramming OK I FOUND YOU