Nested observe calls.

[Lieksu]

Hi there!

UIKitNavigation looks promising and I can't wait to see the details of how it was built.
I've been experimenting with a slightly simplified version of Observable UIKit for the past month and one use-case I just can't get right: initialization of a view that should observe something inside another observe call.

Problem

Here's an example:

@Perceptible
class AuthorsCollectionViewModel {
    var authors: [AuthorViewModel]
}

@Perceptible
class AuthorViewModel {
    var name: String
}

class AuthorsCollectionView {
    let viewModel: AuthorsCollectionViewModel
    var authorViews: [AuthorView]
    
    init(viewModel: AuthorsCollectionViewModel) {
        self.viewModel = viewModel
        
        observe { [weak self] in
            guard let self else { return }
            for author in viewModel.authors {
                let view = AuthorView(author: author)
                authorViews.append(view)
            }
        }
    }
}

class AuthorView {
    let viewModel: AuthorViewModel
    let nameLabel = UILabel()
    
    init(viewModel: AuthorViewModel) {
        self.viewModel = viewModel
        observe { [weak self] in
            guard let self else { return }
            nameLabel.text = author.name
        }
    }
}

My goal is to redraw the collection when the number of elements changes and redraw a single element when its properties change. The problem is that I call AuthorView.init in the observe method, and the name property is accessed inside the observe method in the collection view. If the name property changes, the observe method on the collection is called, and every single view is recreated.

Options I've tried:

• If we allow the observe method to finish and create views on the next tick of the RunLoop, we do not register access to the name property from it. I do not really like this approach as DispatchQueue.main.async is typically used to ensure something is executed on the main thread, not to schedule an operation for the next tick. Mixing @MainActor and DispatchQueue.main.async also does not seem like the way forward.

observe { [weak self] in
   guard let self else { return }
   for author in viewModel.authors {
       DispatchQueue.main.async {
           let view = AuthorView(author: author)
           authorViews.append(view)
       }
   }
}

• We can create views explicitly when the number of elements changes. This way, we still create over-observation in the collection, and this closure will be called when the name changes the first time, but it will not be called subsequent times. As far as I understand, the name property was not called on the second pass, and observation is not registered again, but it stays active in the child view. This looks better, but it is not ideal because it is not obvious to the reader of the code what is happening here and why we have only one unnecessary execution of closure in observe after every necessary one.

observe { [weak self] in
    guard let self else { return }
    for author in viewModel.authors {
        if authorViews.count != viewModel.authors {
            let view = AuthorView(author: author)
            authorViews.append(view)
        }
    }
}

I am curious if this use case is valid and, if so, how you would approach this problem. Any insights or suggestions would be greatly appreciated.

[mbrandonw]

Hi @Lieksu, this is a general problem of "data sources", where you have a collection of data that you want to use to power a collection of views. The same problem exists in collection views, but UIKit provides a nice solution via diffable data sources. Also SwiftUI provides a nice solution via ForEach where it requires each element to be Identifiable so that it knows when items are added/removed/rearranged.

I think the best solution is to basically recreate what UICollectionView and ForEach give us. You would require that the data in your collection be Identifiable (so Author in this case, which would just be the object's referential identity), and then each time observe { … } is called you would figure out how to add/remove/rearrange the subviews for the authors. You will probably want to leverage associated objects from Objective-C to associated the author's ID to the view. This is how we were able to build NavigationStackController that mimics SwiftUI's NavigationStack, which is also very "data source" driven.

And there is probably a general tool we could make to help with this, but we haven't yet figured out its correct shape. We will think about it more.

[Lieksu]

Thanks for the reply @mbrandonw .
I've tried to replicate sort of a diffable data source for my viewmodels. It looks like this:

extension CollectionDifference where ChangeElement: Hashable {
    
    func inferringModifications() -> [Modification<ChangeElement>] {
        let withMoves = inferringMoves()
        var result: [Modification<ChangeElement>] = []
        for change in withMoves {
            switch change {
            case let .insert(offset, element, associatedWith):
                if associatedWith != nil {
                    continue
                }
                if let index = result.firstIndex(where: { $0.remove?.offset == offset }) {
                    let oldElement = result[index].remove!.element
                    result[index] = .update(offset: offset, oldElement: oldElement, newElement: element)
                    continue
                }
                result.append(.insert(offset: offset, element: element))
            case let .remove(offset, element, associatedWith):
                if let associatedWith {
                    result.append(.move(element: element, fromOffset: offset, toOffset: associatedWith))
                    continue
                }
                result.append(.remove(offset: offset, element: element))
            }
        }
        return result
    }
}

and ViewModel for collection can look like this:

class AuthorsCollectionViewModel {
    var viewModels: [AuthorViewModel]
    var models: [Author]
    
    func update(with authors: [Author]) {
        let difference = authors
            .difference(from: models)
            .inferringModifications()
        
        for change in difference {
            switch change {
            case let .insert(offset, element):
                let viewModel = AuthorViewModel(name: author.name)
                viewModels.insert(viewModel, at: offset)
            case let .remove(offset, _):
                viewModel.remove(at: offset)
            case let .update(offset, _, newElement):
                viewModel[offset].name = authors.name
            case let .move(_, fromOffset, toOffset):
                viewModel.move(
                    fromOffsets: IndexSet(integer: fromOffset),
                    toOffset: toOffset
                )
            }
        }
        
        models = authors
    }
}

As far as I understand, if I will do something like this inside observe with collection of hashable child ViewModels - I will get the same problem where I access the name property and observe for collection is called unnecessarily.
Would you suggest to pass model objects for each layer of this nested view structure and check properties of models and not observable ViewModels to decide if changes should be made?
Do I understand correctly, that by passing Author models to each leaf view so that it decides if it should be updated or not - I do not benefit from intermediate observable ViewModels at all?

I apologize in advance if my question is not related to UIKitNavigation beta that much. The topic of minimal rendering and diffable data sources is fascinating to me and it would be great to hear your thoughts.

[mbrandonw]

As far as I understand, if I will do something like this inside observe with collection of hashable child ViewModels - I will get the same problem where I access the name property and observe for collection is called unnecessarily.

I believe you are referring to these lines specifically:

case let .insert(offset, element):
  let viewModel = AuthorViewModel(name: author.name)
  viewModels.insert(viewModel, at: offset)

And yes, it is technically true that since this is called inside an observe, and since author.name is accessed, the observe trailing closure will be called if author.name changes even though technically the parent view does not care about that.

However, this will only cause at most 1 single additional "re-render". If author.name were to change, the observe closure would be invoked again (even though it's not necessary), and in that invocation of the closure author.name will not be accessed, and therefore future mutations to name will not cause the closure to be invoked.

So, it may be slightly unfortunate that we are getting one additional re-render, but it is not a pervasive problem. And really even SwiftUI has this problem. It is possible to construct a model in the body of a view, causing the view to listen for changes in that model even though it doesn't need them. But that "over" observation will lead to at most 1 additional re-render, and then never again.

Does that make sense?

[Lieksu]

Basically this is what I had in this initial attempt:

observe { [weak self] in
    guard let self else { return }
    for author in viewModel.authors {
        if authorViews.count != viewModel.authors {
            let view = AuthorView(author: author)
            authorViews.append(view)
        }
    }
}

It will cause one additional re-render, but no further re-renders if count is the same.
This works, but I thought it is possible to improve it somehow.
Thank you for your time and thoughtful responses.