Getting the source of triggering watch

[anteqkois]

I think it's a good idea to have something that helps debug what triggers the watch.

In my case, I have a ref that changes very frequently, and it's hard to track what exactly caused the change.

watch(
  () => isActiveChartPaneAction.value,
  (newIsActiveChartPaneAction) => {
    console.log('IS_ACTIVE_PANE_CHART_ACTION', newIsActiveChartPaneAction);
    // I need to know what triggered this change
  }
);

I could wrap every assignment to the value, but that would require changing the whole codebase where the value is being set, which is not ideal.

Maybe using a proxy-like wrapper could help, something like this:

const myVar = ref(initialValue);

const myVarWrapper = {
  get value() {
    return myVar.value;
  },
  set value(val) {
    console.trace('myVar was changed to', val);
    myVar.value = val;
  },
};

It's a simple idea, but it could improve the developer experience when debugging reactive variables.

[skirtles-code]

That final example can be implemented using a computed with a setter:

const myVar = ref(initialValue)

const myVarWrapper = computed({
  get() {
    return myVar.value
  },
  set(val) {
    console.trace('myVar was changed to', val)
    myVar.value = val
  }
})

Docs: https://vuejs.org/guide/essentials/computed.html#writable-computed

Using a computed will ensure that Vue treats it as a ref.

[anteqkois]

It's something completely different, it's only example what to track.

[Alfred-Skyblue]

Do you need the following functionality?

watch(
  () => isActiveChartPaneAction.value,
  newIsActiveChartPaneAction => {
    console.log('IS_ACTIVE_PANE_CHART_ACTION', newIsActiveChartPaneAction)
  },
  {
    onTrack(e) {
      console.log(e) // DebuggerEvent
    },
    onTrigger(e) {
      console.log(e) // DebuggerEvent
    },
  },
)

According to the official documentation:
https://vuejs.org/guide/extras/reactivity-in-depth.html#computed-debugging

This is also supported in watch.

[anteqkois]

In half. This gives me a target, but I search for something like when error is thrown. Something like stack to track what part of code trigger this change.

[craigrileyuk]

There's no stack trace or anything that's attached to your watcher. The function you pass as the first argument is run on every tick, and if the return value changes, the 2nd callback is executed.

I doubt the internals even know since the watch source is executed in complete isolation from the code that triggered the change.

watch(
  () => isActiveChartPaneAction.value,
  (newValue, oldValue) => {
    console.log(`${oldValue} changed to ${newValue}`);
  }
);

is about all you have access to.

[skirtles-code]

The function you pass as the first argument is run on every tick

Vue doesn't rely on polling. When that first function (the source) is run, Vue tracks which reactive properties are accessed and stores them as dependencies of the watcher. It will only call the source function again if those properties are assigned new values.

[joebertcerezo]

// I think it's a good idea to have something that helps debug what triggers the watch.
// In my case, I have a ref that changes very frequently, and it's hard to track what exactly caused the change.

watch(
() => isActiveChartPaneAction.value,
(newIsActiveChartPaneAction) => {
console.log('IS_ACTIVE_PANE_CHART_ACTION', newIsActiveChartPaneAction);
// I need to know what triggered this change
}
);

// I could wrap every assignment to the value, but that would require changing the whole codebase where the value is being set, which is not ideal.

// Adding a proxy-like wrapper to log changes to the ref, which helps debug the source of updates without modifying existing assignments.
// Consider enhancing this wrapper with additional metadata (e.g., timestamp, caller function) or integrating with Vue's reactivity debugging tools for more robust tracking.

const myVar = ref(initialValue);

const myVarWrapper = {
get value() {
return myVar.value;
},
set value(val) {
console.trace('myVar was changed to', val);
myVar.value = val;
},
};

// It's a simple idea, but it could improve the developer experience when debugging reactive variables.