fix(solid-query): Fix reconciliation strategy for createBaseQuery #7277
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Fixes #7173
Fixes #7001
The reconciliation strategy for createQuery and createInfiniteQuery has been updated. Previously, the issue with reconciliation was that to preserve the same data reference across different keys, the initial data within the observer was modified to align with the newly fetched data when the query key changed. As this data is also stored in the query cache, such modifications caused the initial data to remain altered. This issue persists on the createResource primitive itself and it makes sense for it since the previous data from a resource cannot be accessed arbitrarily and it also doesn't cache the data. To address this, we now deeply clone the initial data whenever the query data transitions from 'undefined' to any structured form, such as an object or array, using the structuredClone algorithm. This approach ensures that the data associated with the initial queryKey remains unchanged without any mutations.
In the reconcile function callback, we opt not to clone the initial data, instead passing the cached data directly to allow for greater flexibility. However, to ensure proper reconciliation of data between updates, a similar approach to the one outlined in the example below should be followed:
We can provide a utility function that does something similar in the future like
keepPreviousData. I will also document this in the docs since I am already working on a rewrite there too