[Vue warn] Computed is still dirty after getter evaluation

[csicky]

Vue version

3.4.19

Link to minimal reproduction

Steps to reproduce

After the last update I get this warning, but as far as I know I don't have side effects in the computed properties, eslint would warn me about this.
If there are such side effects, the warning is not helping me find them. To make this warning useful it would need to say the name of the computed property. As it is now, it is more just yellow noise in the console.

What is expected?

To either not show warnings, or if it does, to give me the exact name of the computed property and if possible why it thinks it is dirty.

What is actually happening?

I get warnings I can't act upon.

System Info

System:
    OS: Windows 10 10.0.19045
    CPU: (16) x64 AMD Ryzen 7 3700X 8-Core Processor
    Memory: 10.28 GB / 31.93 GB
  Binaries:
    Node: 20.11.0 - C:\Program Files\nodejs\node.EXE
    npm: 10.2.4 - C:\Program Files\nodejs\npm.CMD
  Browsers:
    Edge: Chromium (121.0.2277.112)
    Internet Explorer: 11.0.19041.3636
  npmPackages:
    vue: ^3.4.19 => 3.4.19

Any additional comments?

I am not sure if the computed properties it complains about are actual computed declared in the component or state data imported with mapState or mapGetters

[vladyslav-mikhieiev]

I have a place where the alert points to a ref and this ref can be true or false. However, the component does not have computed. Ref is used to display markup after loading data in onMounted

[solaris7791]

it would be nice if the warning from commit f7ba97f
could be disabled or at least made configurable

It occurs in common scenarios where deeper getter chains may retrigger effects.
As long its no endless recursion (which anyway cause a warning after 100 iterations) it really does not help.

[Doctor-wu]

Hey guys, I'm attempting to add some information about this warning, what information do you think is helpful?

[Doctor-wu]

BTW, I found usePiniaStore in computed will cause this warning, in this case, extract the store to outside can solve this.

[csicky]

Hey guys, I'm attempting to add some information about this warning, what information do you think is helpful?

Hi, it would be helpful to know the name of the computed triggering the warning, also if possible a way to know why the warning was triggered (for example it changed x times in x timespan). I do have in many places computed cascading, like one using up another and on and on, but in my opinion that should not trigger. Also I would like to know if the mapState and mapGetters does trigger this.

[emikoshi]

Agreed with @solaris7791 and @csicky. More information about the name of the computed and why, or at least being able to have some sort of configuration. I linked a pinia playground here showing a simple example of how mapState is triggering this, the discussion related to this is #10340.

It doesn't seem right to me that using mapState should consistently throw this warning. @Doctor-wu could you provide an example of how you are saying this can be solved?

[ayochim]

BTW, I found usePiniaStore in computed will cause this warning, in this case, extract the store to outside can solve this.

Sorry, what do you mean by extract it to outside?

[Doctor-wu]

BTW, I found usePiniaStore in computed will cause this warning, in this case, extract the store to outside can solve this.

Sorry, what do you mean by extract it to outside?
@SirH3nry

[ayochim]

BTW, I found usePiniaStore in computed will cause this warning, in this case, extract the store to outside can solve this.

Sorry, what do you mean by extract it to outside?

Thanks!
Side question: is it even valid for the warning to fire in this scenario? Does using the store this way align with pinia's or vue3's code design goals? I guess my concern is code cleanliness and that this feels kinda band-aid-y

[Doctor-wu]

BTW, I found usePiniaStore in computed will cause this warning, in this case, extract the store to outside can solve this.

Sorry, what do you mean by extract it to outside?

Thanks! Side question: is it even valid for the warning to fire in this scenario? Does using the store this way align with pinia's or vue3's code design goals? I guess my concern is code cleanliness and that this feels kinda band-aid-y

I'm still investigating this, it seems useStore read some reactive data and mutated those data, which made computed dirty. The worse news is mapState or mapGetters used useStore internally which is hard to avoid😢, still working on it

[jsormaz]

BTW, I found usePiniaStore in computed will cause this warning, in this case, extract the store to outside can solve this.

I have a similar usecase, except my Pinia store is dynamically determined within the computed, so I can't really extract it outside the computed

do you have any recommendations?

My thought was to maybe do something like this:

component.vue:

<script setup>
import { pauseTracking, resetTracking } from "@vue/reactivity";

const item = computed(() => {
          const itemType = someDynamicItemType // this comes from an API response or some other dependency
          const itemId = someDynamicItemId

          pauseTracking()
          const store = piniaStoreFactory(itemType)
          resetTracking()

          return store.item(itemId)
     }
)
</script>

data-store.js:

function genericStoreFuncGenerator(itemType) {
     return () => {
          //generic store with some tailoring based on the item type, setup an internal axios instance to a specific API endpoint etc...
         const data = ref({})
         const item = computed(()=> (id)=> data.value[id])

         return {data, item}
     }
}

function piniaStoreFactory(itemType) {
     const useDynamicStore = defineStore(itemType, genericStoreFuncGenerator(itemType))
     return useDynamicStore()
}

Does this seem like a bad idea? I don't really understand the implications of pauseTrack + resetTracking

[lehni]

Hey guys, I'm attempting to add some information about this warning, what information do you think is helpful?

@Doctor-wu I've patched reactivity.esm-bundler.js and runtime-core.esm-bundler.js locally to include the key in the call to computed(), and pass it all the way through to the warning message. It really helps with understanding which part of the code causes the warning. This would be a useful change.

[Doctor-wu]

Hey guys, I'm attempting to add some information about this warning, what information do you think is helpful?

@Doctor-wu I've patched reactivity.esm-bundler.js and runtime-core.esm-bundler.js locally to include the key in the call to computed(), and pass it all the way through to the warning message. It really helps with understanding which part of the code causes the warning. This would be a useful change.

You mean the getter?

[lehni]

@Doctor-wu yes

[Drumstix42]

I don't think this warning makes any sense for simple use cases. As per this comment:

I linked a pinia playground here showing a simple example of how mapState is triggering this, the discussion related to this is #10340.

You can have a simple Pinia store with only state and no computed values, and you stilll get the Pinia warning.

Shouldn't this be considered a bug with Pinia?