Hi Rive team, sharing something we observed and wanted to check whether it's expected behavior or a runtime gap.
We have a state-machine listener on a list-item view model (ItemVM, the item type for a ParentVM/items PropertyList), triggered on Pointer Down. The listener has two set actions, both writing from the row's own VM up to the parent VM:
set ParentVM/itemIndex to ItemVM/index — where ItemVM/index is a List Attributes → Index property (auto-populated row position).set ParentVM/itemId to ItemVM/itemId — where ItemVM/itemId is a String property the app populates at row-push time, before appendInstance.
Action 1 propagates correctly. Swift reads ParentVM/itemIndex via value(of: NumberProperty(path: "itemIndex")) and gets the correct row position on every Pointer Down.
Action 2 does not appear to propagate. Swift reads ParentVM/itemId via value(of: StringProperty(path: "itemId")) — the property exists (no "could not find property" error), but the value comes back empty even though ItemVM/itemId is verifiably non-empty for that row (the row's own bound text run on the same artboard renders the value correctly, and reading it directly through a per-row wrapper returns the right value).
Both actions live on the same listener and the same trigger event. The only differences are the source property type (Number vs. String) and the source kind (List Attributes Index vs. user-bound). The editor accepts the configuration without warning.
What makes this look like a list-item-VM-listener-context gap rather than a String-write gap in general: we've separately verified that String literal writes and Trigger fires propagate correctly across VM tiers when the listener lives on a script-instantiated child artboard (an Input<Artboard<X>>:instance()-rendered child whose own state-machine listener writes to a different VM). Same data-binding mechanism, same destination property type — different host context for the listener, and that one works. Cross-VM writes from main-artboard button listeners also work for arbitrary types in our app.
Is the cross-VM set pipeline expected to handle arbitrary user-bound Strings on list-item-VM listeners specifically, or is the auto-populated List Attributes Index path the only one supported from that context? Happy to share a minimal .riv repro and Swift logs if it's a runtime gap.
(Same behavior on rive-ios 6.19.1 and on rive-app/rive-ios main HEAD 082bf9d. Separately filed an unrelated CommandQueue listener-handle issue on rive-runtime as #95 — flagging in case there's any shared causation around the same VMI surface, though the mechanism appears different.)
Hi Rive team, sharing something we observed and wanted to check whether it's expected behavior or a runtime gap.
We have a state-machine listener on a list-item view model (
ItemVM, the item type for aParentVM/itemsPropertyList), triggered on Pointer Down. The listener has twosetactions, both writing from the row's own VM up to the parent VM:set ParentVM/itemIndex to ItemVM/index— whereItemVM/indexis aList Attributes → Indexproperty (auto-populated row position).set ParentVM/itemId to ItemVM/itemId— whereItemVM/itemIdis a String property the app populates at row-push time, beforeappendInstance.Action 1 propagates correctly. Swift reads
ParentVM/itemIndexviavalue(of: NumberProperty(path: "itemIndex"))and gets the correct row position on every Pointer Down.Action 2 does not appear to propagate. Swift reads
ParentVM/itemIdviavalue(of: StringProperty(path: "itemId"))— the property exists (no "could not find property" error), but the value comes back empty even thoughItemVM/itemIdis verifiably non-empty for that row (the row's own bound text run on the same artboard renders the value correctly, and reading it directly through a per-row wrapper returns the right value).Both actions live on the same listener and the same trigger event. The only differences are the source property type (Number vs. String) and the source kind (List Attributes Index vs. user-bound). The editor accepts the configuration without warning.
What makes this look like a list-item-VM-listener-context gap rather than a String-write gap in general: we've separately verified that String literal writes and Trigger fires propagate correctly across VM tiers when the listener lives on a script-instantiated child artboard (an
Input<Artboard<X>>:instance()-rendered child whose own state-machine listener writes to a different VM). Same data-binding mechanism, same destination property type — different host context for the listener, and that one works. Cross-VM writes from main-artboard button listeners also work for arbitrary types in our app.Is the cross-VM
setpipeline expected to handle arbitrary user-bound Strings on list-item-VM listeners specifically, or is the auto-populated List Attributes Index path the only one supported from that context? Happy to share a minimal.rivrepro and Swift logs if it's a runtime gap.(Same behavior on rive-ios 6.19.1 and on
rive-app/rive-iosmain HEAD082bf9d. Separately filed an unrelated CommandQueue listener-handle issue on rive-runtime as #95 — flagging in case there's any shared causation around the same VMI surface, though the mechanism appears different.)