Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[Possible Bug] QueryKey evaluated after component is unmounted #155

Closed
tobiasdcl opened this issue Jan 8, 2025 · 1 comment
Closed

[Possible Bug] QueryKey evaluated after component is unmounted #155

tobiasdcl opened this issue Jan 8, 2025 · 1 comment
Labels
🐞 bug this isn't working as expected

Comments

@tobiasdcl
Copy link

Hi there,
I might have found another issue, although this could also be a wrong expectation on my side.

When the key in useQuery is reactive it is re-evaluated here inside of the onUnmounted hook.

This can cause unexpected behaviour if the dependencies of the reactive key have changed like shown in the reproduction below.
I am not 100% sure if this is expected or not but it feels a bit weird. I think instead of re-evaluating the key its latest value should be stored so that it can be used in the onUnmounted hook - but again my understanding of how this is intended to work might be wrong 😄

I am curious about your take on this 🙌


reproduction:

Here we have a simple Component that is using useQuery:

<template>
  <div>
    <h1>SubComponent</h1>
    <br />
    Key: {{ key }}
    <br />
    Data: {{ data }}
  </div>
</template>

<script setup lang="ts">
const props = defineProps({
  queryKeyPart: {
    type: Object as PropType<{ foo: string }>,
    required: true,
  },
});

const key = computed(() => {
  const result = ['common', props.queryKeyPart.foo];

  console.log('evaluated computed property - value:', JSON.stringify(result));
  console.log('props.queryKeyPart.foo should always be a string, hence I can call .length on it:', props.queryKeyPart.foo.length);

  return result;
});

onUnmounted(() => {
  console.log('sub component unmounted - nothing should happen anymore');
});

const { data } = useQuery({
  key,
  query: async () => Promise.resolve('query result'),
});
</script>

the component is used here:

<template>
  <div>
    <!-- we only render the sub-component if `queryKeyPart.foo` is truthy because the component requires it to be present -->
    <sub-component v-if="queryKeyPart.foo" :query-key-part="queryKeyPart" />
    <button @click="clickhandler">Trigger</button>
  </div>
</template>

<script setup>
const queryKeyPart = ref({ foo: 'bar' });

function clickhandler() {
  console.log('clickhandler invoked');
  queryKeyPart.value.foo = undefined;
}
</script>

console output:

evaluated computed property - value: ["common","bar"]
SubComponent.vue:23 props.queryKeyPart.foo should always be a string, hence I can call .length on it: 3

When the button is clicked queryKeyPart.value.foo is set to undefined. Due to the v-if="queryKeyPart.foo" the sub-component should be unmounted - which it does - but the computed property of the query key is re-evaluated afterwards.

console output:

clickhandler invoked
SubComponent.vue:29 sub component unmounted - nothing should happen anymore
SubComponent.vue:22 evaluated computed property - value: ["common",null]
Uncaught (in promise) TypeError: Cannot read properties of undefined (reading 'length')
    at ComputedRefImpl.fn (SubComponent.vue:23:123)
    at refreshComputed (reactivity.esm-bundler.js:380:28)
    at isDirty (reactivity.esm-bundler.js:350:68)
    at refreshComputed (reactivity.esm-bundler.js:370:63)
    at get value (reactivity.esm-bundler.js:1631:5)
    at use-query.ts:238:32
    at runtime-core.esm-bundler.js:2815:40
    at callWithErrorHandling (runtime-core.esm-bundler.js:199:19)
    at callWithAsyncErrorHandling (runtime-core.esm-bundler.js:206:17)
    at hook.__weh.hook.__weh (runtime-core.esm-bundler.js:2795:19)
@github-project-automation github-project-automation bot moved this to 🆕 Triaging in Pinia Colada Roadmap Jan 8, 2025
@posva posva moved this from 🆕 Triaging to Todo in Pinia Colada Roadmap Jan 10, 2025
@posva posva added the 🐞 bug this isn't working as expected label Jan 10, 2025
@posva
Copy link
Owner

posva commented Jan 10, 2025

Thanks for the detailed repro!

@posva posva closed this as completed in e2ff278 Jan 14, 2025
@github-project-automation github-project-automation bot moved this from Todo to Done in Pinia Colada Roadmap Jan 14, 2025
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
🐞 bug this isn't working as expected
Projects
Status: Done
Development

No branches or pull requests

2 participants