RFC: @tanstack/query/prefer-query-options

[Newbie012]

Separating queryKey and queryFn can cause unexpected runtime issues when the same query key is accidentally used with more than one queryFn.

Rule Details

Examples of incorrect code for this rule:

/* eslint "@tanstack/query/prefer-query-options": "error" */

function Component({ id }) {
  const query = useQuery({
    queryKey: ["get", id],
    queryFn: () => Api.get(`/foo/${id}`),
  });
  // ...
}

/* eslint "@tanstack/query/prefer-query-options": "error" */

function useFooQuery() {
  return useQuery({
    queryKey: ["get", id],
    queryFn: () => Api.get(`/foo/${id}`),
  });
}

Examples of correct code for this rule:

/* eslint "@tanstack/query/prefer-query-options": "error" */

const options = queryOptions({
  queryKey: ["get", id],
  queryFn: () => Api.get(`/foo/${id}`)
});

function Component({ id }) {
  const query = useQuery(options);
  // ...
}

/* eslint "@tanstack/query/prefer-query-options": "error" */

const options = queryOptions({
  queryKey: ["get", id],
  queryFn: () => Api.get(`/foo/${id}`),
});

function useFooQuery() {
  return useQuery({ ...options, select: (data) => data.foo });
}

Options

ignorePatterns

An array of strings used to ignore specific query key patterns:

{
  "@tanstack/query/prefer-query-options": [
    "error",
    {
      "ignorePatterns": {
        "startsWith": ["ignore-key"],
        "endsWith": ["ignore-key"],
        "includes": ["ignore-key"],
      }
    }
  ]
}

collections

An array of strings used to enforce the use of queryOptions in specific collections of queries:

{
  "@tanstack/query/prefer-query-options": [
    "error",
    {
      "collections": ["fooQueries", "deeply.nested.queries"]
    }
  ]
}

When Not To Use It

If you do not want to enforce the use of queryOptions in your codebase, you will not need this rule.

Attributes

• ✅ Recommended
• 🔧 Fixable.

[TkDodo]

love it ❤️ . One question that remains is if we want to add this to the recommended ruleset, and if so, on which level ?

[Newbie012]

While I do advocate for co-locating queryKey and queryFn I feel like this rule is a bit more opinionated than the others. Maybe we could add recommendedStrict config and add it there.