Best way to wrapper defineQuery

[Hanmo123]

To query user posts in multiple components that are mounted at the same time, i tried to wrapper defineQuery like below:

export const useUserPostsQuery = defineQuery(() => {
  console.log("defineQuery executed");

  const route = useRoute();

  return useQuery({
    key: () => ["users", route.params.user_id.toString(), "posts"],
    query() {
      console.log("user posts query executed");
      return UserApi.getPosts(route.params.user_id.toString());
    },
    enabled: () => !!route.params.user_id
  });
});

This example works well in UserPostsView, however, after calling userUserPostsQuery(), the key started to be watched: the query will also executed in other view that contains user_id params like UserFollowersView, which does not need to load user's posts.

I know that i can limit the route.id that uses this query, i wonder is there a better practice in this situation like auto pause the query when route changes.

[posva]

The enabled option shouldn't be needed in pages for most cases but it's indeed the way to go to limit queries that are used across pages. The one I've seen most often is in Nuxt because they have to render the app tree twice. If the query is used in a global scope (e.g. a store), then it's also needed because the query becomes global and always active.

Where are you calling useUserPostQuery() exactly?

[Hanmo123]

It seems that you may not get it well😂, in view depends on the posts data, the setup fn of them called useUserPostQuery, the query became active, when routing to any other view, key of the query changes and the query will be re-execute(if no enabled fn provided), which sometimes unnecessary

i am looking for a way to do something like unload the query when route change

[posva]

as mentioned, a boiled down repro could help in case this is a bug. It's impossible to check any further. Also, in Nuxt, this is normal

[Hanmo123]

Thank you for your response. Here is some additional information:

• I did not use nuxt.
• I have created a minimal reproducible demo, which can be found here: https://github.com/Hanmo123/pinia-colada-discussion-221

The steps to reproduce are as follows:

1. Go to postview: The console logs 'query defined' and 'query called'.
2. Then wait for the response: The console logs 'query resolved'.
3. Go to userview: This page does not call usePostsQuery, so there is no new output in the console. This indicates that queryFn was not called, which is exactly what I want.
4. Go to homeview: This page also does not call usePostsQuery.

During the fourth step, an error occurs:
post.ts:9 Uncaught (in promise) TypeError: Cannot read properties of undefined (reading 'toString')
(This error led me to mistakenly believe that the query was being called repeatedly and now i see the reason why we should set enabled field.)
It seems that pinia-colada is attempting to compute a new query key, but since this view does not call usePostsQuery, this behavior might be unnecessary?

---

Addition:

When route changes and enabled fn returns false, key will also be computed.

Currently, this query below works well, it will try to call query fn only in views which call usePostsQuery:

export const usePostsQuery = defineQuery(() => {
  console.log('query defined')

  const route = useRoute()
  return useQuery({
    key: () => ['posts', route.params.user_id?.toString()],
    query: () => {
      console.log('query called')
      return new Promise((resolve) => {
        setTimeout(() => {
          console.log('query resolved')
          resolve([
            {
              id: 1,
              title: 'foo',
              body: 'bar',
              user_id: 1,
            },
          ])
        }, 1000)
      })
    },
  })
})

[posva]

Created #227 to track. Using useQuery() doesn't show this behavior, so this should be fixable

[sumerokr]

I also want to participate in this discussion, since I cannot wrap my head around this use case.
Let's say we have these views:

/posts/:postId // renders the post itself, needs post data
/posts/:postId/edit // renders the post to edit, needs post data

/posts/:postId/comments // renders the post comments only, doesn't need post data
/posts/:postId/tags // renders the post tags only, doesn't need post data

To keep post query organized, we do defineQuery like this

export const usePost = defineQuery(() => {
  const route = useRoute()
  return useQuery({
    key: () => ['posts', Number(route.params.postId)],
    query: () => fetch(`/api/posts/${route.params.postId}`),
    // only enable the query when there is a :postId param in the route
    enabled: () => 'postId' in route.params,
  });
});

This approach works fine for the first two views mentioned above.
But it will also be triggered (for no meaningful reason) for the last two views mentioned above.
What would be the best way to solve this puzzle? Putting more route related information like route names

enabled: () => route.name === 'Post' || route.name === 'PostEdit',

doesn't feel right 🤔

[sumerokr]

I have to admit that I haven't really used it this way yet, just trying to wrap my head around the docs.
I would use it in both /posts/:postId and /posts/:postId/edit views, but not in the latter two, of course.

[posva]

Then you shouldn't even need the enabled flag unless what was mentioned above: #221 (comment)

[sumerokr]

Sounds good, thanks for the answer! I'll give it a try in a day or two and get back to this topic if it something is not clear 👍

[sumerokr]

Just have tried it (I use 0.13.6 version at the moment). Here is my query

// /src/queries/use-post
export const usePost = defineQuery(() => {
  const route = useRoute();
  return useQuery({
    key: () => ['posts', String(route.params.postId)],
    query: () => fetchPost({ postId: route.params.postId }),
  });
});

When I navigate from /posts/:postId (that uses usePost query) to /posts/:postId/comments (that doesn't use usePost query)

• query function is not executed (desired behaviour)

When I navigate from /posts/:postId (that uses usePost query) to /home (that doesn't use usePost query)

• query function is executed and results in an error, since route.params.postId is undefined

Adding enabled: () => "postId" in route.params helps in my case.

[posva]

This was foxed but not released yet #227