Giter VIP home page Giter VIP logo

Comments (5)

brunolopesr-dft avatar brunolopesr-dft commented on July 17, 2024 2

The enabled property of a query controls whether the query should start the fetch lifecycle or not. If the query cache was already populated for a given queryKey, the data property will return it, even if enabled = false

Following your example, if the page is something that is used to retrieve a new set of data, it should be included in the queryKey along with other properties. If the enabled property is false when the page changes from 1 to 2, it will not start the fetch, you can observe that by looking at the fetchStatus property that will be idle, the data then will stay at undefined.

If the data for the page 2, in this scenario, was already populated for example in another place of your app or by prefetching, even if enabled = false, it will be returned by the useQuery if it is still available in the cache.

To show or not to show the data should be controled by you in your app, not by React Query.

from query.

dany-pellerin avatar dany-pellerin commented on July 17, 2024

The enabled property of a query controls whether the query should start the fetch lifecycle or not. If the query cache was already populated for a given queryKey, the data property will return it, even if enabled = false

Following your example, if the page is something that is used to retrieve a new set of data, it should be included in the queryKey along with other properties. If the enabled property is false when the page changes from 1 to 2, it will not start the fetch, you can observe that by looking at the fetchStatus property that will be idle, the data then will stay at undefined.

If the data for the page 2, in this scenario, was already populated for example in another place of your app or by prefetching, even if enabled = false, it will be returned by the useQuery if it is still available in the cache.

To show or not to show the data should be controled by you in your app, not by React Query.

I understand what you're saying, maybe the use case I've given is not clear enough. Maybe I should've started a discussion instead of raising an issue.

The way I see it is there should be a distinction between a paused query, I would expect a paused query to be temporarily disabled and return what is in the cache, if anything. On the other hand, as a user I would expect an enabled query that is disabled to not hit the network and not hit the cache either. It's disabled, it shouldn't return anything (at least that's what I believe users would expect).

along with other properties

I am not going to provide very specific implementation details, but we are using typescript and some auto-generated code, and the object that we are passing to the useQuery function always has the same structure, it is strongly typed, imagine something like:

{
   someProperty: undefined // whatever type this would be
}

In the first instance we are not using someProperty but we still need to provide it because of strong typing, in the other case we only want to show the result when the property is defined, so it's disabled if someProperty is undefined. We are getting a very unexpected behavior in our app because of that. This is a simplified explanation of what is happening.

Based on what you are saying, we have 2 options, either we ditch the strongly typed code, which we don't want, or we add logic in a wrapper that when it's not enabled it doesn't return the result. It's not ideal but it's not a big deal either.

I looked in the documentation and there's no mention of that design decision (not enabled returns the cached result if any). It took me by surprise and I think it could be the same for other people. That design choice is up to you, but as a user of the library it can be very unexpected. Maybe I just missed it in the doc, but if I didn't, I would highly suggest that you update the documentation and add more details about what enabled does.

Thank you!

from query.

TkDodo avatar TkDodo commented on July 17, 2024

The docs say:

If you ever want to disable a query from automatically running, you can use the enabled = false option.

When you call useQuery, you are still creating an observer that watches the cache entry for that key. If data is available, it will be given to you. If data gets in the cache by some means, the component will re-render. Otherwise, you would have a component that is subscribed to a query that could never re-render.

In the first instance we are not using someProperty but we still need to provide it because of strong typing

I don't fully understand your use-case. Seems like you have created some abstraction that is kinda in the way?

FWIW, I think you want to look into the skipToken we provide to automatically disable a query in a type-safe way. We also have an abstraction where we provide a url and required options, something like:

useQuery(fooQuery('/api/foo/$id', { params: path: { id : 1 }})

now id is required because it's part of the path, but what if id starts as undefined and becomes defined later? What we do is:

useQuery(fooQuery('/api/foo/$id', id ? { params: path: { id : 1 }} : skipToken)

skipToken can be imported from @tanstack/react-query, and if passed as the queryFn, the query will not run. See: https://tanstack.com/query/latest/docs/framework/react/guides/disabling-queries/#typesafe-disabling-of-queries-using-skiptoken

from query.

dany-pellerin avatar dany-pellerin commented on July 17, 2024

I don't fully understand your use-case. Seems like you have created some abstraction that is kinda in the way?

It's one way to put it, yes. We never had an issue with it before, it's actually been very useful and made our transition from v4 to v5 easier. It seems like this is an edge case.

I think you want to look into the skipToken we provide to automatically disable a query in a type-safe way

Based on the description it seems like this would work. I feel like it would be a workaround since the skipToken was not explicitly designed for that purpose. It feels a little a little clunky imo, at this point we'll have an internal discussion about it. Appreciate the help.

Thanks.

from query.

Abibibi avatar Abibibi commented on July 17, 2024

The enabled property of a query controls whether the query should start the fetch lifecycle or not. If the query cache was already populated for a given queryKey, the data property will return it, even if enabled = false

Following your example, if the page is something that is used to retrieve a new set of data, it should be included in the queryKey along with other properties. If the enabled property is false when the page changes from 1 to 2, it will not start the fetch, you can observe that by looking at the fetchStatus property that will be idle, the data then will stay at undefined.

If the data for the page 2, in this scenario, was already populated for example in another place of your app or by prefetching, even if enabled = false, it will be returned by the useQuery if it is still available in the cache.

To show or not to show the data should be controled by you in your app, not by React Query.

Thanks, it worked perfectly well for me

from query.

Related Issues (20)

Recommend Projects

  • React photo React

    A declarative, efficient, and flexible JavaScript library for building user interfaces.

  • Vue.js photo Vue.js

    🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.

  • Typescript photo Typescript

    TypeScript is a superset of JavaScript that compiles to clean JavaScript output.

  • TensorFlow photo TensorFlow

    An Open Source Machine Learning Framework for Everyone

  • Django photo Django

    The Web framework for perfectionists with deadlines.

  • D3 photo D3

    Bring data to life with SVG, Canvas and HTML. 📊📈🎉

Recommend Topics

  • javascript

    JavaScript (JS) is a lightweight interpreted programming language with first-class functions.

  • web

    Some thing interesting about web. New door for the world.

  • server

    A server is a program made to process requests and deliver data to clients.

  • Machine learning

    Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.

  • Game

    Some thing interesting about game, make everyone happy.

Recommend Org

  • Facebook photo Facebook

    We are working to build community through open source technology. NB: members must have two-factor auth.

  • Microsoft photo Microsoft

    Open source projects and samples from Microsoft.

  • Google photo Google

    Google ❤️ Open Source for everyone.

  • D3 photo D3

    Data-Driven Documents codes.