Changes need for integration into liveview-client-swiftui

[simlay]

Related to:

• LiveView Native Clients: Use uniffi bindings for uses of liveview-native-core-swift liveview-client-swiftui#1210
• LiveView Native Clients: Use uniffi bindings for uses of liveview-native-core-jetpack liveview-client-jetpack#414

[carson-katri]

Suggested change

	if !children.isEmpty {
	if let node = children[children.count - 1].next() {
	children.append(node.children().makeIterator())
	return node
	} else {
	children.removeLast()
	return self.next()
	}
	} else {
	return nil
	}
	guard !children.isEmpty else { return nil }
	if let node = children.last?.next() {
	children.append(node.children().makeIterator())
	return node
	} else {
	children.removeLast()
	return self.next()
	}

[carson-katri]

It'd be nice if we could have an AsyncStream for this API.

[simlay]

Well I refactored this a few times to fix a deadlock. When mergeFragmentJson is called, it's locking a mutex for the Document on the rust side as it's mutating the document. Today, I pulled in latest main liveview-native/liveview-client-swiftui#1287 and found that recent changes to ObservedElement caused the deadlock. This is in part because when the closure is called on an incremental edit update, elementChanged which triggers the sink closure on the ObservedElement which uses Document.subscript and Document.children which require read locks on the same mutex that's currently locked for editing. I wonder if an AsyncStream for this API would help?

[carson-katri]

elementChanged could be refactored to publish the element, instead of just Void. Then the child caching could be done on read instead of when the change occurs.