[runtime-vapor] UI does not update correctly when reactive data changes

[Kaidesuyoo]

Vue version

3.6.0-beta.10

Link to minimal reproduction

Playground

Steps to reproduce

vapor-mode.mp4

What is expected?

vDom.mp4

What is actually happening?

In Vapor mode, UI updates (v-for) behave inconsistently depending on whether list is a shallowRef or a ref.

When list is a shallowRef:

• the update pattern used in change1 does not trigger a UI update
• the update pattern used in change2 does not trigger a UI update

When list is a normal ref:

• only the update pattern used in change1 fails to trigger a UI update
• the other update patterns work as expected

The same code works correctly in the latest stable version (VDom), where all update patterns trigger UI updates normally.

System Info

System:
  OS: Windows 11 10.0.26200
Binaries:
  Node: 22.22.1
Browsers:
  Chrome: 148.0.7778.97

Additional comments

From my initial observation, the issue seems to be related to the itemRef variable inside the mount function of the apiCreateFor file.

It appears that itemRef is using the original source value returned by getItem. Later, when the data changes and the update function is called, the UI update is skipped because newItem and itemRef from the ForBlock instance still reference the same object and are therefore considered unchanged.

[edison1105]

This is currently an intentional performance trade-off in Vapor. see #12985 (comment)

Unlike VDOM, Vapor's v-for updates list structure and row content through separate reactive paths. If the list is a shallowRef of raw objects, mutating a nested field on the same object does not provide a row-level reactive signal:

row.label = 'updated'
triggerRef(rows)

The recommended pattern is to make mutable row fields reactive explicitly:

const rows = shallowRef([
  { id: 1, label: shallowRef('foo') }
])

rows.value[0].label.value = 'bar'

This keeps list structure updates cheap while allowing row content updates to be precise.

see playground

[Kaidesuyoo]

Yes, I initially also tried to fix this issue myself.

However, every approach I came up with inevitably introduced some additional performance overhead, which is why I decided to open this issue instead.

So for now, should I understand this as an intentional behavioral change that could potentially be considered breaking compared to the current VDOM behavior?

[edison1105]

Yes, that's a fair interpretation, with one nuance: I would describe it as an intentional performance trade-off / current limitation in Vapor rather than a bug.

Vapor's v-for updates list structure and row content through separate reactive paths. triggerRef(rows) updates the list source, but if a reused row still points to the same raw object, the row effect does not automatically re-run. VDOM behaves differently because the parent render is re-executed and item expressions are read again.

So if a row field is expected to update independently, it should provide its own reactive signal, e.g. make that field a ref, or replace the changed row object.

This keeps list updates cheap while making row content updates explicit and precise.

[Kaidesuyoo]

Got it, that makes sense now.

This update model actually feels similar to Solid's fine-grained reactivity approach.

Thanks for the clarification, and thanks to the Vue team for the continued work on Vapor — I'm really looking forward to it.