I have a table (i.e. "List") with a large number of rows. (Say 1000. Say 10,000. Who knows.). The rows show images which are loaded from a remote server. The images are fetched lazily, so it is highly likely that if one scrolls fast enough, any given row of the table may display not the actual image, but a placeholder until the image is available.
Prior to SwiftUI, the way I would do this is have a model backend which, when it loads an image, sends out a "signal" that an image with path P (i.e. some string identifying the image) is ready. The UITableViewController would have kept a map that says for any existing cell, what image that cell cares about. If the UITableViewController sees that an image that some existing cell cares about has been modified, it would reload JUST THAT ROW (updating a placeholder image, or switching out an activity spinner to the actual image).
I believe in SwiftUI that I also want to be that performant: if the backend finishes loading an image, I only to update the row for that image. The way I'm doing this now is making a large number of very small BindableObject instances, and having each row hang onto that instance with an @ObjectBindingproperty wrapper. When an image finishes loading, I grab the bindable object corresponding to that image and make its didChange() variable fire.
This seems to work OK, but
(1) Each of these small bindable object instances has to be a class, not a struct.
(2) So we're creating a lot of PassthroughSubject objects.
Is this really the right way to get fine-grain notification? Would it/does it scale? Is there something better? I mean, I love how easy it is to do, and OMG, it's a lot simpler, bookkeeping wise than what I had before, and for sure, it doesn't even try to redraw anything that's way offscreen if you update the data, but want to make sure this is right.
