[Vue warn] Computed is still dirty after getter evaluation
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
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
it would be nice if the warning from commit https://github.com/vuejs/core/commit/f7ba97f9754a9882c1f6b1c07ca1a4040479dd13 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.
Hey guys, I'm attempting to add some information about this warning, what information do you think is helpful?
BTW, I found usePiniaStore in computed will cause this warning, in this case, extract the store to outside can solve this.
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.
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?
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?
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
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
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
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
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.
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
andruntime-core.esm-bundler.js
locally to include thekey
in the call tocomputed()
, 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?
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 https://github.com/vuejs/core/discussions/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?
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?
Agreed, that's because mapState
use useStore
internally and useStore
has side-effect.
Started a discussion on Pinia's side. Not sure if creating a bug is appropriate. https://github.com/vuejs/pinia/discussions/2585
@Doctor-wu yes
https://github.com/vuejs/core/pull/10386 Here's a PR for this A sample for warning👇🏻, click on the function can jump to the source in devtools
I'm getting this warning without pinia in a component – occurs for me whenever I add a nuxtUI element.
I'm getting this warning without pinia in a component – occurs for me whenever I add a nuxtUI element.
i started a nuxt3 project from scratch to investigate this warning.. just v-calendar module installed and.... warning flood
@Doctor-wu yes
#10386 Here's a PR for this A sample for warning👇🏻, click on the function can jump to the source in devtools
@Doctor-wu I haven't been getting this warning anymore since upgrading to x.20. Did something change?