`triggerRef` does not trigger `watch(() => ref.value)`

[undergroundwires]

Vue version

3.3.8

Minimal reproduction

This test fails:

import { nextTick } from 'vue'
test('triggerRef with watch', async () => {
    const a = shallowRef(1)
    let aTriggered = false
    watch(() => a.value, () => {
      aTriggered = true
    })
    triggerRef(a)

    await nextTick()  

    expect(aTriggered).toBe(true)
  })

What is expected?

Watching values of manually triggered references should execute the watch callback.

What is actually happening?

Watching the ref itself works fine. According to post by @LinusBorg in #1209 (comment), this is the expected design of Vue.

However, getting value of the ref does not work. So watch(() => a.value, ...) won't work but, watch(a, ...) work. The behavior should be the same and consistent for shallowRefs where state tracking is disabled

watchEffect works fine for these .value calls. This is another undocumented inconsistency with watch.

Official Vue docs state nothing about caching for watch.

[LinusBorg]

My linked comment is incorrect as it relates to triggerRef. I was, at that moment, more focused on the asynchronous execution of the test. Further down in the linked issue'S comments, Evan explains why the watch callback should not execute in these cases - because the callback should only run if the value actually changed, which is also documented as such, in my opinion.

(Sidenote: watchEffect is different as it doesn't have a callback, it essentially is a watch with just the first argument - only the effect, not the callback. And the effect runs on any trigger, yes.)

The real inconsistency that I noticed is that the behaviour you desire is only happening if the first argument is a shallowRef:

const a = shallowRef(0)
watch(a, () => console.log('this will trigger'))
watch(() => a.value () => console.log(''this will not'))

playground

Looking at the implementation of watch() this could be by design? I have to call in @yyx990803 to get some insight in the desired behaviour.

I can presume this was done so that one can use watch() when doing mutations to in non-reactive content in a shallowRef's value, but I personally think this behaviour is confusing, especially since it only works with the ref as the argument, not a getter reading the ref.

Though I could imagine that there's already userland code out there relying on this behavior, which we don't want to break, necessarily.

if we keep this behavior, we need to properly document it as a special behavior of watch() with shallowRef()

[WORMSS]

This seems like the same problem I am having with passing in a shallowRef() into a prop of a child component.

I 'KNOW' the internals of a object (in my case, a arrayBuffer) have changed, so I call triggerRef() but a child component's internal computed never retrigger.

Everything inside the outer component updates as you would expect, but the child component just sits there oblivious. (Which is very counter intuitive, that only half of the reactivity system would update).

It seemed #9732 had the same problem, but it was closed and locked.

[miroljub1995]

Hello @LinusBorg and @yyx990803
I came across some weird situation, maybe related to this issue. In the following example, I do not get updates of counter, but if I uncomment <!-- <h1>Directrly from nested: {{ obj.nestedObj.count }}</h1> --> then both lines render counter as it changes:

<script setup>
import { onMounted, shallowRef, triggerRef, computed } from 'vue'

// This can be from some external library that has no knowledge of vue, like Fabricjs
class SomeFrameworkObject extends EventTarget {
  constructor() {
    super();

    this.nestedObj = { count: 0 };
    setInterval(() => {
      this.nestedObj.count++;
      this.dispatchEvent(new Event("modified"))
    }, 1000);
  }
}

const obj = shallowRef(new SomeFrameworkObject());

onMounted(() => {
  obj.value.addEventListener("modified", () => triggerRef(obj))
})

const nestedObj = computed(() => obj.value.nestedObj);
</script>

<template>
  <!-- <h1>Directrly from nested: {{ obj.nestedObj.count }}</h1> -->
  <h1>From computed: {{ nestedObj.count }}</h1>
</template>

[LinusBorg]

That example works as expected.

Triggering the obj ref makes the computed re-evaluate, but since it returns the same value, that will not trigger a rerender of the template.

If you access the obj ref in the template, then it re-renders because it's now a direct dependency of the template

[miroljub1995]

Thanks for the clarification. Do you have a suggestion on how to create reusable computed values for some third-party objects that are mutated without reactivity proxies?

[ratijas]

That example works as expected.

Respectfully, it pretty much doesn't. I told it to trigger, I expect it to trigger and cascade all the way down. Who told Vue.js that it gets to decide what has changed and what hasn't (in a language without == operator overloads btw), especially overriding my explicit intentions? This seems like a real blocker.

I wanted to split some computation into chunks, and you are telling me I should slice() a huge Float32Array every frame just to fix broken signal propagation? (or is that "effect propagation"? Coming from Qt/QML background, I don't know the terminology here).

Sure enough, if I replace it

-    triggerRef(peaks);
+    peaks.value = new Float32Array(0);
+    peaks.value = waveform;

then it works. But it is an unreasonable "solution".

[WORMSS]

@ratijas oooh, I never considered flipping to a fake object and back again..
Seems it shouldn't be needed, since that is the whole purpose of what triggerRef() should be doing in the first place, but at least I can get rid of my worse work-around now which was to use a number ref that I increment when I know my arrayBuffer has changed, and so I then read from the array buffer when the number updates..

[ratijas]

@ratijas oooh, I never considered flipping to a fake object and back again..

well, in Qt land where properties can only be fully controlled (manually signaled) from C++ side, but only auto-magically subscribed to and propagated in QML, I've seen things worse than this, like

• wrapping methods as properties/refs, so they can be manually signaled to be re-evaluated whenever their dependencies in native code change, because there is no magic when reading props in C++
• or explicitly reading but discarding a related property/ref, often combined with a , comma operator in single-line expressions, just to incur a READ/subscription, only because someone deeper in the stack forgot to emit/trigger change signal for its dependent property, etc.

So the nature of workarounds doesn't really surprise me. It's rather that maintainers don't seem to acknowledge these issues as worth fixing. The watch signature is quite complicated, and while it's true that the equality check is mentioned in the docs -- who's got time to read through all those caveats? It's not even a bullet point of its own, it is mentioned in the middle of a paragraph after "In addition," words. In another paragraph it says:

watch is lazy by default: the callback won't be called until the watched source has changed.

with no way to opt out from said default. That section is a bit misleading, because immediate: true is different from "the watched source has changed" concept.

---

I think the problem with Vue.js is that it shifts events deduplication onto thee receiving end, and also only does it sometimes. Normally, property setters go like this:

void setMyProperty(P newValue) {
  if (this._myProperty != newValue) {
    // ...custom logic...
    this._myProperty = newValue;
    emit myPropertyChanged();
  }
}

Particular syntax doesn't matter, the idea is universal. You can use custom equality operator, or even choose to not cut the corners at all. You are the one to decide.

Vue.js instead shifts the responsibility, so now the subscribers like watch have to cache an oldValue, and they insist on doing equality checks for you. You are no longer the one in control, and there are no escape hatches, even though there were supposed to be some like triggerRef.

watchEffect(() => {
  console.log("REDRAW");
  redraw(waveform.peaks.value);
}, {
  onTrigger: () => console.log("TRIGGER")
});

// elsewhere
while (!areWeDoneYet()) {
  calculateBatch(peaks);
  triggerRef(peaks);
}
// prints TRIGGER a bunch of times,
// but REDRAW never does.