Should LVN core produce a unique element identifier for each element when it parses for SwiftUI to tag each view with?

[bcardarella]

There are a lot of upcoming needs to query the view tree to accomplish optimistic UI. This may be a common problem for other potential clients in the future. To enable the querying I believe we can accomplish this through LVN core that already has a cache of the view tree and can use any selector-based query engine to traverse and retrieve the matching element. Then the already generated ID is passed back to the client for looking up by that unique tag value.

This could be overridable as well so if the developer includes a defined id attribute then that value is used instead. We'd have to permit the possibility of duplicate id values, it would be last wins.

The generated IDs could be used when we implement our version of JS commands. I think we'll call them Native commands. In LiveView CSS selectors are permitted to be used to query the element action will take place upon. We can allow for this if we enable the querying method I outlined above.

With the Native commands we'd mimic the same API which will produce a set of commands that the client can run on the target element.

[carson-katri]

Each node already has a NodeRef, which is a unique numerical ID for each element.

[bcardarella]

@carson-katri but can we use that in the way I described?

[carson-katri]

I think core would just have some API like document.query("some selector") that returns a list of NodeRefs (which are just Int ids for nodes).

// update all elements with the class `blue`:
for id in document.query(".blue") {
  self.elementChanged(id).send()
}