hasChanged behavior in the Vue 3.4 reactivity system

[beskar-developer]

Hi. I have a scenario that has a different outcome in different versions of vue!

<template>
  {{ items }}
</template>

<script setup>
  import { computed, reactive, watch } from "vue";

  const someArray = [Math.random(), Math.random(), Math.random()];

  const someReactive = reactive({
    dir: "asc",
    execute(items) {
      return items.sort((a, b) => (this.dir === "asc" ? a - b : b - a));
    },
  });

  const items = computed(() => {
    const sortedItems = someReactive.execute(someArray);

    console.log("computed triggered", sortedItems);

    return sortedItems;
  });

  watch(
    items,
    () => {
      console.log("watch is triggered", items.value);
    },
    {
      deep: true,
    },
  );

  setTimeout(() => {
    someReactive.dir = "desc";
  }, 1500);
</script>

In vue 3.3 the computed, watch, and render are triggered and the array is changed.
In vue 3.4 the computed is triggered but watch and render do not!
I think this is some sort of BREAKING CHANGE behavior if it is not a bug. I know that 3.4 is checking for reference and if I do [...sortedItems] it will work the same, but if the current code works differently in different versions of vue it may be a breaking change!

This scenario is related to this #5912 PR and I'm not sure if this is a bug, a breaking change, or just an expected behavior!

[4refael]

[beskar-developer]

This is just a simplified version of some code that I took from a table component but in general anywhere that computed returns a reference of an array it may work differently in different versions of vue!

[skirtles-code]

There are several problems with this example, but the main problem is that someArray is not reactive. That might be fine if the array wasn't being modified, but it is being modified by the call to sort. If you make someArray reactive then it will work fine:

• Playground

If you modify non-reactive data then Vue's behaviour is undefined. It might work, it might not. This isn't something that is guaranteed to stay the same between versions.

[beskar-developer]

I think your example is not relevant. In your example computed is triggered at first for the dir change and then in the 3.3 version watch is triggered but it is not in 3.4 (the returned value of computed is actually changed in this state due to dir change). Then because the reactive has changed it will trigger computed once more and watch in both 3.3 and 3.4.
In the mentioned PR the new reactivity system is applied on computed, render, and watch and not reactive.
As I said the code is a simplified version of a table component and the items come from props.items and it did not work there but the props have reactivity itself.

[basvanmeurs]

As mentioned in another thread:

This computed sorts someArray in place, which means it always returns the same reference. Since 3.4 computeds have become lazy. If the result is equal (as in this case, given it is the same reference) it will not trigger deps.

Solution may be to return a new array when using the sort function, using return [...sortedItems] in the computed.

[beskar-developer]

I understand this change in 3.4 and I mentioned reference check several times in this thread or another one. But what I meant is that if such a behavior is expected it can be mentioned as a breaking change or something else(not sure what!) in documents, because it has different behavior in different versions!

[basvanmeurs]

Nowhere in the specs it has been specified whether computeds should always trigger if they are triggered, or they should only do so if the produced value changes. So that implies that no specification was broken.

[beskar-developer]

I think this is the definition and the main use case of computed. It is too odd if the value is changed but it does not update the DOM! The main purpose that is mentioned in the document is to remove complexity from template and move it to computed properties so if the computed value is actually changed the render must happen!

[LinusBorg]

the computed wasn't changed, though, because "the computed changed" is decided by its return value. and its return value is still the same, non-reactive array.

The fact that you did mutate this non-reactive array is not observable by Vue (because it's not a reactive array). So Vue thinks there's no reason to update anything - nothing reactive changed.

In the old implementation, computed's would have to trigger dependent effects reagrdless of weither their return value changed, which could cause performance problems as it can trigger unnecessary updates quite often depending on the circumstances. This old behaviour was not desirable / by design, but all attempts to solve it before 3.4 failed.

So the change in 3.4 is a performance optimization that has been asked for for a long time.

Your example essentially relies on the unnecessary computed update to have non-reactive changes still "trigger" updates.

[beskar-developer]

Thanks for your answer! It seems more reasonable now!