Avoid computing computed with `storeToRefs()`

[Ericlm]

Reproduction

https://github.com/Ericlm/pinia-computed

Steps to reproduce the bug

Since version 2.2.5, computed values are evaluated at the start even if they're not displayed (when using storeToRefs).

It may be related to 254eec7

Expected behavior

The computed should only be evaluated when it is actually used.

Actual behavior

The computed is evaluated even if its value is displayed inside a v-if="false".

Additional information

No response

[posva]

This seems to be inherent to Vue's toRef(). The same behavior exists in regular Vue. If you want to avoid computation, you can directly reference the store with store.doubleCount or pass () => store.doubleCount.

A possible improvement here would be to change the current implementation related to HMR in order to keep using the old version in storeToRefs() that references the raw store object (thus not triggering reactivity). Contribution welcome.

Edit: I'm not completely sure we want to revert this change because if this behavior exists in current Vue, it's more natural to keep it. That being said I would like to have real world examples of why this change affects you

[sceee]

I understand that this might be according to Vue's toRef(), but nevertheless this seems to be like a pretty big change in behavior.
In my case, it seems to "break" a lot of stuff as it just behaved different until now and therefore was used in that way.

@posva as I'm not sure I understood your tips regarding avoiding computation correctly (and I can unfortunately also not view your "play" link as it throws an exception InvalidCharacterError: Failed to execute 'atob' on 'Window': The string to be decoded is not correctly encoded. which seems to be a general vue play error at the moment):

What exactly do you mean with "you can directly reference the store"?
To use this

const { myComputedProp } = myStore

instead of

const { myComputedProp } = storeToRefs(myStore)

?
But this is then no longer reactive, is it?

Or what do you mean with your other mentioned fix "pass () => store.doubleComputed"?
This:

const myComputedProp = computed(() => myStore.myComputedProp)

?

Thanks.

[posva]

I updated my comment with a fixed link. In your case, it seems like you can simply not use storeToRefs() at all. The real use case for it is to pass the extracted ref to another composable. Most of the time, these composables also accept a getter function () => store.computed, which is why I'm suggesting the getter

In my case, it seems to "break" a lot of stuff as it just behaved different until now and therefore was used in that way.

Interested in learning more and available to help as well!

[marr]

Most of the time, these composables also accept a getter function () => store.computed, which is why I'm suggesting the getter

I'd like to understand this more thoroughly. In the app I'm working on, we seem to use storeToRefs all over the place. I use computed quite often and thought I would have to use the .value of the transformed (via storeToRefs) ref. If this is not the case, can you tell us how that works? Since computed depends on reactive values, how would it work just referencing store.foo since that doesn't seem to be reactive?

[posva]

store.foo is reactive because store is a reactive object

[marr]

If I do something like this, I don't see updates:

  watchEffect(() => {
    console.log(store.foo)
  });

[marr]

Is there something wrong with how I'm using the store here?
https://stackblitz.com/edit/nuxt-pinia-ssr-qwpymm?file=app.vue

[posva]

Yes, you are returning a plain string:

But it seems that the t function doesn't keep reactivity because it doesn't work within a computed either. If I were you, I would check with nuxt i18n

Otherwise, it works

[chuchiperriman]

Same problem here. Variables are being evaluated before being read when we use storeToRef.

This change is not compatible with previous functionality and breaks all components that use the store.