Arrays keep previous items after refetch when a client property is included #4474
Comments
|
As a side note. I would expect this to be a blocker for 2.5 release, since this is just basic usage and a regression from previous versions |
|
Thanks for reporting this @NickClark. We've noticed this as well, and will have it fixed before 2.5 is released. |
hwillson
added a commit
that referenced
this issue
Feb 25, 2019
In an effort to simulate `defaults` behaviour from `apollo-link-state`, we're leveraging cache results when running local resolvers. The idea being that if a local resolver isn't defined for a `@client` field, the local resolver handling code can then fallback on using any matching cache results, to resolve the field. While this works in theory, it has introduced a few problems, like the one reported in the field value, when they shouldn't be used. Since local resolvers adhere to Apollo Client's query fetch policy, by defalut the cache is consulted first, when trying to resolve a `@client` field. This means we shouldn't need to attempt to resolve from the cache again, when processing local resolvers, in most cases. There are a few situations where we might want to do this, but the requirements are theoretical at this point, and can be addressed in future changes if needed. This commit removes the extra cache check, and adds a test to verify that the behaviour reported in #4474 is fixed.
hwillson
added a commit
that referenced
this issue
Feb 25, 2019
In an effort to simulate `defaults` behaviour from `apollo-link-state`, we're leveraging cache results when running local resolvers. The idea being that if a local resolver isn't defined for a `@client` field, the local resolver handling code can then fallback on using any matching cache results, to resolve the field. While this works in theory, it has introduced a few problems, like the one reported in #4474. Since local resolvers adhere to Apollo Client's query fetch policy, by defalut the cache is consulted first, when trying to resolve a `@client` field. This means we shouldn't need to attempt to resolve from the cache again, when processing local resolvers, in most cases. There are a few situations where we might want to do this, but the requirements are theoretical at this point, and can be addressed in future changes if needed. This commit removes the extra cache check, and adds a test to verify that the behaviour reported in #4474 is fixed.
|
@NickClark This should now be fixed using the latest Apollo Client / React Apollo RC's ( |
Sign up for free
to subscribe to this conversation on GitHub.
Already have an account?
Sign in.
Intended outcome:
I expect, when refetching, to get the latest data as it comes from the server, but with my added client attributes
Actual outcome:
Currently, with the latest beta, this is broken. When loading data with new elements, they tend to be persisted.
How to reproduce the issue:
I've made a simple server and client here:
Server:
Client:
Versions
Apollo Client 2.5.0-beta.1
The text was updated successfully, but these errors were encountered: