Disabled queries is successful from start?

[anddoutoi]

I have two components that loads the same data and shares query key but one does it "on demand" by mounting useQuery with options.enabled set to false.

I however gets status success even if options.enabled is false.

• Is this expected?

If this is expected…

• what is the reasoning behind this?

How to "fix it"?

• Is queryResult.refetch() the only alternative here?
• What conditional should I use to not render the data in my demand component?

https://codesandbox.io/s/react-query-on-demand-fcj6hy?file=/src/App.js

import {useState} from "react";
import {QueryClientProvider, QueryClient, useQuery} from "react-query";

const queryClient = new QueryClient();

export default function App() {
  return (
    <QueryClientProvider client={queryClient}>
      <div className="App">
        <Gizmo />
        <hr />
        <GizmoOnDemand />
      </div>
    </QueryClientProvider>
  );
}

function Gizmo() {
  const gizmoQueryResult = useQuery(["gizmo"], fetchGizmo);

  return (
    <div>
      {gizmoQueryResult.isIdle ? <div>Idle</div> : null}
      {gizmoQueryResult.isLoading ? <div>Loading</div> : null}
      {gizmoQueryResult.isSuccess ? (
        <div>Success: {gizmoQueryResult.data.name}</div>
      ) : null}
    </div>
  );
}

function GizmoOnDemand() {
  const [isEnabled, setEnabled] = useState(false);

  const gizmoQueryResult = useQuery(["gizmo"], fetchGizmo, {
    enabled: isEnabled
  });

  return (
    <div>
      <button onClick={() => setEnabled(true)}>Fetch Gizmo</button>
      {gizmoQueryResult.isIdle ? <div>Idle</div> : null}
      {gizmoQueryResult.isLoading ? <div>Loading</div> : null}
      {gizmoQueryResult.isSuccess ? (
        <div>Success: {gizmoQueryResult.data.name}</div>
      ) : null}
    </div>
  );
}

function fetchGizmo() {
  return Promise.resolve({ name: "Gizmo" });
}

[TkDodo]

if both queries share the same query key then yes, this is expected. You'll also get the data returned. For each key, there is one cache entry. If you create a second subscriber (via useQuery), that one will pick up the same data as the other one. enabled just controls if this query can trigger a fetch or not.

So success means that there is data for this queryKey in the cache, independent from who triggered the fetch. Not sure what you are trying to achieve, but if you don't want to show the gizmo data even though there is data in the cache for gizmo - use a different key I guess ?

[anddoutoi]

Why do you not want to show data for gizmo even though you have data already in the cache?

It's a design/UX requirement 🤷‍♂️

In our case it's also about the query keys being dynamic and they are all created by using your query key creators pattern.

This is what happens. A dependant query is mounted with data derived from another "parent" query. Sometimes the derived data is "invalid" and is creating a null value. If that happens we Promise.reject in the query function as you described in other discussions about handling invalid values. This dependant query is creating a query key like ["entity", "search", {q: null}].

Later a user mounts a different view where the the user can search for an "entity". It's in this view we have enabled set to false and waiting for a valid use input. When this view is mounted the key created from the start is ["entity", "search", {q: null}] and the entire idling state is bypassed and we get right into the isSuccess conditional. This was very surprising.

[TkDodo]

this sounds like you'd want: enabled: q !== null with a key of ["entity", "search", { q }]. Unless you have data in the cache for the null query, you wouldn't get a successful query state. So how would you have data for for q:null in the cache if it's invalid?

[anddoutoi]

So how would you have data for for q:null in the cache if it's invalid?

No idea really. The query option that is created in our query factory looks like this:

{
  queryKey: createGizmosSearchKey(filter),
  queryFn() {
  return isNull(filter)
    ? Promise.reject(new Error(errorMessage))
    : api
      .searchGizmos({filter})
      .then(({data}) => data.map((item) => Gizmo.fromJSON(item)));
  },
  ...options,
}

and the query key factory looks like this:

function createGizmosSearchKey(filter: ApiSearchFilter | null) {
  return ["gizmos", "search", {filter}];
}

It's the dependant query that puts it in the cache even being a "rejected" query. The "on demand" query then later "picks" this up from the query cache when it mounts with the same generated key.

[TkDodo]

It's the dependant query that puts it in the cache even being a "rejected" query. The "on demand" query then later "picks" this up from the query cache when it mounts with the same generated key.

the rejected promise in the queryFn is basically just a way to make typescript happy, because filter passed in can still be null. I'm guessing you have that pattern from: https://tkdodo.eu/blog/react-query-and-type-script#type-safety-with-the-enabled-option

anyways, the query shouldn't run with null filters. You have to make sure of that with the enabled option. With the shown code, the query should go to error state after retries. It cannot be in success state if you have a rejected promise.

The failure is likely that a query with a null filter is not disabled. What I would do is, roughly:

const useGizmo = (filter, options) => useQuery({
  ...options,
  queryKey: createGizmosSearchKey(filter),
  queryFn() {
  return isNull(filter)
    ? Promise.reject(new Error(errorMessage))
    : api
      .searchGizmos({filter})
      .then(({data}) => data.map((item) => Gizmo.fromJSON(item)));
  },
  enabled: isNull(filter) ? false : options.enabled
})

function Gizmo() {
  const gizmoQueryResult = useGizmo({ name: "myGizmo" })

  return (
    <div>
      {gizmoQueryResult.isIdle ? <div>Idle</div> : null}
      {gizmoQueryResult.isLoading ? <div>Loading</div> : null}
      {gizmoQueryResult.isSuccess ? (
        <div>Success: {gizmoQueryResult.data.name}</div>
      ) : null}
    </div>
  );
}

function GizmoOnDemand() {
  const [filter, setFilter] = useState(null);

  const gizmoQueryResult = useGizmo(filter)

  return (
    <div>
      <button onClick={() => setFilter({ name: "myGizmo" })}>Fetch Gizmo</button>
      {gizmoQueryResult.isIdle ? <div>Idle</div> : null}
      {gizmoQueryResult.isLoading ? <div>Loading</div> : null}
      {gizmoQueryResult.isSuccess ? (
        <div>Success: {gizmoQueryResult.data.name}</div>
      ) : null}
    </div>
  );
}

the Gizmo component will then instantly fetch for the key ["gizmos", "search", { name: "myGizmo" }];. The GizmoOnDemand on the other hand will first render with the null filter, which give you a disabled query. Then, after the filters are set, it will change the key to ["gizmos", "search", { name: "myGizmo" }];, which might give you data from the cache instantly if it exists + a background refetch, or, it will go to hard loading state + fetch it if the data does not yet exist in the cache.

Hope that clears things up a bit.

[anddoutoi]

I'll have to take some time to try this out. Initial gut feeling is that you're on to something here @TkDodo and it looks promising.

Huge thank you for your time and suggestion!