There may be times when you already have the initial data for a query synchronously available in your app. If and when this is the case, you can use the
config.initialData option to set the initial data for a query and skip the first round of fetching!
When providing an
initialData value that is anything other than
statuswill initialize in a
successstate instead of
isStaleproperty will initialize as
true. This can be overridden by setting the
initialStaleis set to
If the process for accessing a query's initial data is intensive or just not something you want to perform on every render, you can pass a function as the
initialData value. This function will be executed only once when the query is initialized, saving you precious memory and CPU:
In some circumstances, you may be able to provide the initial data for a query from the cached result of another. A good example of this would be searching the cached data from a todos list query for an individual todo item, then using that as the initial data for your individual todo query:
Most of the time, this pattern works well, but if the source query you're using to look up the initial data from is old, you may not want to use the data at all and just fetch from the server. To make this decision easier, you can use the
queryCache.getQuery method instead to get more information about the source query, including a
query.state.updatedAt timestamp you can use to decide if the query is "fresh" enough for your needs:
initialData is not considered stale, but sometimes you may want it to be, for instance, if your initial data is only a partial subset of an object and you know you will need to refetch the full version immediately after mounting. For this, you can use the
initialStale: true options.
initialData will be considered
stale and will cause a refetch when the query mounts for the first time.
NOTE: Similar to
initialStalecan also be a function for costly calculations.
initialStale: () => isPreview(todoListPreview)