Are there any stories on the Backlog to explore query prefetching with the the QueryClient?

[vinclou]

Hey, I was wondering if there are any stories in the backlog exploring the option of using something like the following for the core data hooks:

Something like the following could be in the core:

  // ... some code
  const queryClient = useQueryClient();
  // trigger a prefetch query after some side-effect or trigger a prefetch of a query that has not been triggered yet
  queryClient.prefetchQuery(...myDataProviderParamsForAPage)

Yet, since the v4 upgrade made Refine much more flexible in what you can do with QueryClient the user of the library can
write their own utilities for it, if Refine provides a utility to build the same query parameters as the core hooks do:

T.e screenshot of the query string as an example:

[omeraplak]

Hey @vinclou ,
Great idea, how do you think we should present the DX?

[vinclou]

---

I believe that prefetching, although a niche area, does have occasional significance. Its potential, in terms of DX and UX when implemented at the core level, can be illustrated as follows:

Scenario:

Imagine navigating to the show/edit page, which contains multiple tabs and, let's say, five navigation options. Under the current system, if a user were to navigate between these options, all the unmounted components would initiate loading. This results in the user encountering a loading spinner when transitioning to the next page. An ideal approach would be to prefetch the data at the root level, ensuring a smoother user experience. This would allow users to instantly access data for subsequent pages, as it was prefetched in the background. (Well technically you can do it now as well if u really wanted to. by merely declaring data fetching hooks like useTable at that page => and pass the props down, through context, or just use the hook again in the unmounted component, performance won't be hurt much, since tanstack-query is just a bunch of observables underthehood)

And you can see why this is less than ideal - the code duplication is massive & optimizations will only make the code less readable
and obscure -> What I feel like Refine excels at is letting writing non-react devs or beginners good code without all the pitfalls and verbosity of React

Side note: since I've made the migration to Refine from vanilla React, my PR reviews became so much easier, in my current company all other frontend devs are actually Angular ppl.. not even sure why they made this UI in React back in a day, well huh at least now backend devs and angular devs can reliably contribute ;)

Implementation Options for DX:

1. Direct Integration with Core Hooks: One could simply introduce a boolean parameter to the core hooks. For example, passing a boolean to initiate prefetching in the useOne, useList, etc. However, this might necessitate substantial updates throughout the framework and may not be the ideal solution given the potential for numerous edge cases. (I acknowledge that I might not be as deeply familiar with Refine as you are.)

2. Utility Hook for Prefetching: A more efficient option might be to provide users with a utility hook, allowing them to replicate the filters used by the core hooks. Based on the URL information shared earlier, this approach seems simpler. As a framework user, I'm familiar with the parameters and can decide when and how prefetching should occur, if needed. This method requires less work for SPAs and a little more exploration for SSR frameworks. Importantly, it doesn't hinder the development of other features and, being an isolated new core hook, it ensures that no existing functionality will break.

3. DataProvider Level: I won't delve deep into this, but it appears to be the least flexible option. Given that users already manage the dataProvider, any custom requirements in the dataProvider should be user-implemented.

---