New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Merge function at the type level not working (+ suggested fix) #11808
Comments
is for merging one patient with another patient. The error message you are getting here though is about merging Have you tried (assuming that a diagnosis is of the
? |
Thank you for the fast response @phryneas!
Ah! It looks like I misunderstood the feature. What you suggest indeed works. |
No, merging happens on a type level - we don't look at parent types, only at fields of a type.
I believe this would be possible with a fuzzy type policy (by creating a virtual supertype this is not very well documented):
but tbh., I'd want to recommend against that, and urge you to be more explicit - add |
That fuzzy type policy works perfectly, thank you! |
The problem is now that you will miss it if a JSON blog was switched to a completely different JSON blob. I would recommend that you at least restrict it a bit, e.g. if your JSON blob types all end with
Alternatively, in your Schema definition you could have all of their types extend an common interface and then use the graphql-codegen to generate a |
I see your point. Right now we don't have anything that distinguishes them but maybe we'll add that. I also now understand the spirit of the feature, but after reviewing I don't think we have a use case anywhere where we have non-normalized objects that are switched, only updated, the other cases are always id-normalized. (I would actually think that's the default for non-normalized object types in general, and that there's some exceptions that require replacing) |
Simple example where something will go very wrong easily: inserting an item to a list or removing one. Query 1 returns: [ { name: "Tim", height: 185}, { name: "Bob", height: 175 }, { name: "Alice", height: 179 } ] now you delete one object, retreive the same list, but now with a "lastName" instead of [ { name: "Tim", lastName: "Foo" }, { name: "Alice", lastName: "Bar" } ] Your cache will probably end up with something like this, with a wrong height for "Alice": [ { name: "Tim", height: 185, lastName: "Foo"}, { name: "Alice", height: 175, lastName: "Bar" } ] I'm just saying... be careful with |
Oh maybe it's wasn't clear, I'm just talking about plain objects, arrays should definitely be replaced or custom merged. Does the above merge all fuzzy type policy also makes apollo try to merge arrays? If so I can probably replace the |
It's not so much about "array or not", it's more about a missing knowledge about identity here. It's not about merging two arrays, but about the question if individual array elements are the same object or completely different objects. But tbh., I'm slightly unsure here if that would really happen with arrays like this - you best give it a try, though, to be sure! |
Got it, my point is more: in our specific context we don't have non-normalized plain objects changing identity. For arrays (where we wanted the type policy to still replace them):
Just tested and for future reference can confirm the resulting array in the cache is [ { name: "Tim", lastName: "Foo" }, { name: "Alice", lastName: "Bar" } ] From my side the issue can be closed, thanks for your support @phryneas ! |
Okay, closing then :) Happy to help! |
Do you have any feedback for the maintainers? Please tell us by taking a one-minute survey. Your responses will help us understand Apollo Client usage and allow us to serve you better. |
Issue Description
Defining a merge function at the type level doesn't seem to be working for me.
With the cache defined as
I get the warning
And the data is overwritten in the cache.
Note: the diagnosis is a Patient object property with a typename but without an id
but with
it works.
My theory is that the parent typename is not considered when doing the merge function lookup. I tried adapting the policies.ts's
getMergeFunction
to take this into consideration:and it works as expected = no warnings and fields are all merged.
Any thoughts?
Link to Reproduction
let me know if it's not clear
Reproduction Steps
No response
@apollo/client
version3.9.11
The text was updated successfully, but these errors were encountered: