Thoughts on light abstractions and patterns?

[derekr]

The react-query API is great as is, but as I'm adding more queries and hitting scenarios for invalidating caches and/or prefetching and refetching I'm wondering if folks have been playing around with making queries and query concerns more portable.

I may have to invalidate a cache or prime a cache in different parts of my codebase (usually on mount or as an app initially renders) and I may need to do this for the same query in multiple locations (mostly due to legacy setup and wanting to migrate things over time vs big refactor). The issue I'm seeing is needing to pass a key builder around when performing some of these action in addition to the method for interacting with the cache. I think the use case isn't so important since I think the general issue of needing the cache key (when wanting to clear an exact cache) could be common enough

import { useCache } from 'react-query'

// const buildProductKey = (productId, params) => ['product', productId, params]
import { buildProductKey } from './hooks/use-product'

const SomeAdjacentPage = ({ productId }) => {
  const cache = useCache()
  cache.invalidateQueries(buildProductKey(productId))
}

That example is trivial and the alternative without any abstractions isn't much different or that complex, but I think encapsulating the prefix, type or brand (whatever you'd want to call that key prefix) has benefits.

Wondering if there's a point to be made to maybe include some of the react-query cache utilities on the hook or near the hook.

// module
// useProduct essentially a thin wrapper around useQuery and accepts the same arguments as useQuery
// useProduct([productId, { someParam: true }], { staleTime: 300000 })...
const { useProduct, ...otherExports } = makeQuery(
    keyPrefix: 'product',
    fetchProducts,
    // params would be request params or any other config relating to the actual data
    // passed in to useProduct and used in the react-query key
    selectData: (data, params) => {
      // can maybe include some other APIs for consistently processing returned 
      // data at the hook level. I only include this as there may be more concerns that 
      // make sense to keep close to the hook that handle shared setup/config as other 
      // query hooks in your app.
    }
)

export default useProduct
exports = otherExports

// caller
import useProduct, { prefetch, refetch } from 'hooks/use-product'

Could play around with more ergonomic and friendly exports, but in general all the utility functions would have the same signature as the hook (where building a key is concerned).

import { useProduct } from 'hooks/use-product'
useProduct.prefetch(productId)

Anyway not driving this too seriously at the moment, but was curious if anyone else was starting to work on patterns/higher-level APIs on top of react-query.

[tannerlinsley]

From day 1, the recommendation has always been to encapsulate reusable query logic into custom hooks.

export default function useProduct (productId, options) {
  return useQuery(['products', productId], () => fetchProductById(productId), options)
}

Does this not suffice?

[tannerlinsley]

Yeah, you could do that too. It's all just different way of approach. You could also say that creating constants or functions to ensure key consistency is just as good.

[derekr]

Yeah that's why I'm asking to see what other approaches folks are taking to poke holes in my thinking and get some inspiration. Mostly curious and not trying to push any one abstraction or pattern and am currently passing around constants/functions for ensuring consistency.

[jansedlon]

Hello @derekr . It's been a long time since you created this discussion. Have you come across anything? I've been doing basically the same thing that Tanner Linsley suggested with a bit of a generics added to have customized TContext that can differ from mutation to mutation but nothing else.

[jansedlon]

I also don't like adding 20 lines of code for optimistic updates for each mutation in a component. Were you able to find an abstraction to outsource it?

[moshfeu]

@jansedlon have you found / built something. When I first thought about adopting query I'd hope to avoid dealing with the cache directly (apis like getQueryData, setQueryData etc.).