• Find real-case scenarios where this is used to evaluate how important this feature is
• Ideally should be tree shakable (a plugin)

• test signals aborts if refetch is called

It could be interesting to have a way to filter queries when we look for some specific queries in the cache (a usecase could be the useQueriesState composable, cf #23).

For example, here is the query filter provided by TanStack Query : https://tanstack.com/query/latest/docs/framework/react/guides/filters#query-filters

It seems that the removeDep function is not called in the context of a query declared with the defineQuery composable. More precisely, the onScopeDispose hook seems not to be called.

Not sure if it is relevant, but I noticed that the scopes are not the same for a query declared with the useQuery composable and the defineQuery composable.

In the useQuery context:

And in the defineQuery context:

Note: I will provide later the demo of these two cases.

• Quick Start
  • Installation
  • Introduction
  • Playsink
• Guides
  • Queries
  • Query keys
  • Cache and refreshing data
  • Mutations
  • Optimistic updates
    • UI
    • Cache
• Plugins
• Cookbook

This will allow later on to retrieve mutation state, cancel ongoing mutations etc. By default mutations have no key and cannot be "reused"

Allowing a query to be preloaded
Requires all the options rather than just the key as otherwise it might not exist

Currently, every time useQuery is called, it registers callbacks for the visibilitychange and online events (if options.refetchOnWindowFocus or options.refetchOnReconnect are set to true).

Could we consider the introduction of a focus manager and online manager mechanism? This approach would allow us to manage subscriptions to changes in focus and online status uniformly, rather than registering new events each time.

maybe a defineQuery(() => {}) to allow using globals and creating global state associated with the query (e.g. a page?).

Currently one can try to do this:

<script setup lang="ts">
const page = ref(1)
useQuery({
  query() {
     return fetchData(page.value)
  },
  key: () => ['key', page.value]
})
<script>

But this can fail in some scenarios, notably if the same key is used in a different component or if this gets abstracted with

export const useSomeData = () => {
const page = ref(1)
return useQuery({
  query() {
     return fetchData(page.value)
  },
  key: () => ['key', page.value]
})
}

and used in multiple components, the page will end up scoped to the first component that calls it. Both components will create a page ref but only the first one will be used within query and key. Therefore, if the first component is unmounted while the other still lives, the page ref will not be reactive anymore, breaking the usage.

Notes

• An eslint plugin could warn agains this usage. It would be better to have some runtime warning but not sure how to do it, maybe checking for the active scope and saving it somewhere in dev only?
• Maybe run within a computed and check its deps
• The function version is nice to setup initial state. Each query/mutation is effectively a mini store

Add methods to mutations to handle optimistic data updates

• Allow passing new options + types
• hook into setup()
• Move features to plugins
  • refetch on mount?
  • Invalidate keys

So, when fetching with the apollo client all the fetched data lands in the normalized cache of apollo. Would there be any benefit in using pinia-colada or pinia in general to do the fetching other that maybe global availability, which would not be in issue since requests are cached anyway.

TS now supports type narrowing when destructuring. So it's worth having multiple types for the return values of useQuery and useMutation

import { Ref, ShallowRef, ref, shallowRef } from "vue";

interface UseStuffReturnOn<T> {
  state: Ref<'on'>
  data: ShallowRef<T>
}

interface UseStuffReturnOff<T> {
  state: Ref<'off'>
  data: ShallowRef<T | undefined>
}

type UseStuffReturn<T> = UseStuffReturnOff<T> | UseStuffReturnOn<T>

export function useStuff<T>(initial: T): UseStuffReturn<T> {
  return {
    state: ref('on'),
    data: shallowRef(initial)
  }
}

const { data, state } = useStuff(0)

if (state.value === 'on') {
  data.value.toFixed()
}

• Demo

Allows retrieving the query state by key

• Should allow passing multiple keys to to match multiple queries and return the aggregated state of these queries
• How should they combine data, error, and status? Should each have an individual array, an object, a map?
• If the state doesn't exist, create it?
• It should handle a reactive version of the matched keys

Same questions for useMutationState()

Allows getting access to only the state, creates it if it doesn't exist. Requires #17

Add query handlers for loading paginated / "infinite" data

Create a mutation store to hold the share state of mutation

Add a mutation plugin that allows setting up global options (onSuccess, etc that run after local ones)

This avoids cache to grow indefinitely