useStorage - v9.8.2 introduced breaking change - watcher on nested object triggered despite not changed

[robinpilz]

Describe the bug

We just updated @vueuse/core from v.9.6.0 to 9.12.0 and it seems like there is a breaking change introduced in v9.8.2 likely to be a bug.

We have a scenario where we store an object in the form of { one: { name: "foo" }, two: { name: "bar" } } in local storage using useStorage.

Then we have a watcher on storage.value.one which resets storage.value.two to undefined.
Then we have a watcher on storage.value.two doing something else
Then we have some select fields updating storage.value.one and storage.value.two

localStorage.setItem(
  "test",
  JSON.stringify({ one: { name: "foo" }, two: { name: "bar" } })
);
const storage = useStorage("test", {});

watch(
  () => storage.value.one,
  (val) => {
    console.log("one changed", val);
    storage.value.two = undefined;
  }
);
watch(
  () => storage.value.two,
  (val) => {
    console.log("two changed", val);
  }
);

With v9.6.0 when updating storage.value.two only the watcher on storage.value.two would be called as one would expect.

With version >= 9.8.2 however the watcher for storage.value.two is called 2 times
then the watcher for storage.value.one is called, resetting storage.value.two to undefined
then the watcher for storage.value.two is called again, with a new value of undefined
and funny thing, storage.value.two in local storage is not even resetted 😃

Reproduction

https://codesandbox.io/s/twilight-sea-33kwm3?file=/src/App.vue

System Info

vue: 3.2.45
@vueuse/core: >= 9.8.2
Browser: Google Chrome Version 110.0.5481.78 (Offizieller Build) (64-Bit)

Used Package Manager

npm

Validations

• Follow our Code of Conduct
• Read the Contributing Guidelines.
• Read the docs.
• Check that there isn't already an issue that reports the same bug to avoid creating a duplicate.
• Make sure this is a VueUse issue and not a framework-specific issue. For example, if it's a Vue SFC related bug, it should likely be reported to https://github.com/vuejs/core instead.
• Check that this is a concrete bug. For Q&A open a GitHub Discussion.
• The provided reproduction is a minimal reproducible example of the bug.

[rafaellehmkuhl]

I can confirm the behavior.

[jdk2pq]

I think this may be related to this issue as well, which still appears to be a problem in the latest release.

[AndreiSoroka]

I have a not similar but related problem. When used with the Module Federation, the useStore becomes non-reactive

[stale]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

[rafaellehmkuhl]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

The problem persists.

[stale]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

[maartenbrakkee]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

The problem persists.

[Codermar]

"@vueuse/core": "10.4.1", has a similar issue described here #3312.
It causes infinite loop

[stale]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

[6XGate]

Well the fix that closed this ticket now prevents useStorage from reading the current value in storage when creating the reactive value. useLocalStorage will be return a reference with an undefined value even if there is a value in the backing store. I'll try to make a repro repo for it and file a ticket soon.

[stale]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.