apollographql
Add documentation for "fuzzy" `possibleTypes`
Issue Description
Adds documentation for the ability to specify "fuzzy" or heuristic subtype matching. See details in https://github.com/apollographql/apollo-client/pull/6901.
Link to Reproduction
N/A
Reproduction Steps
No response
This would be very much appreciated.
I am currently facing an issue where a fuzzy type is not being matched due to a nullable field being null in the response.
I am reluctant to open a new issue because this may actually be intended behaviour. Documentation might clear this up for me. Examples of what would pass matching rules and what wouldn't pass matching rules would be useful.
I am currently facing an issue where a fuzzy type is not being matched due to a nullable field being null in the response.
I'm facing exactly the same thing today.
I wonder if @benjamn might be able to weigh in? Is selectionSetMatchesResult supposed to be so strict? For example I have a field in my selection set which might give an object with various subfields, or may return null. Either is valid. But the response is being thrown out if it has a null there.
It feels like a bug to me, but maybe it's an intentional limitation of the fuzzy matching behaviour?
@tremby @jonnyleeharris thanks for flagging this. I have an idea of what might be going on here after chatting with Ben, but I haven't been able to reproduce the issue yet. If either of you are able to share a reproduction, or a more detailed example, that would be much appreciated.
Edit: of course, immediately after posting I was able to recreate the bug. I'll share any more info as soon as I have it :) thanks.
@tremby I've created an issue https://github.com/apollographql/apollo-client/issues/11522 and opened a draft PR with a failing test https://github.com/apollographql/apollo-client/pull/11521/files. If you have a moment, would you be able to look at the failing test and let me know if that looks like what you're seeing? If there's a related-but-different one you're seeing, that would be useful info, too.
@alessbell, the title of it ("typePolicies can be inherited from supertypes with fuzzy possibleTypes, with null returned for a nullable field on a fragment") definitely sounds like what I want and am not getting. The body of it, I find it hard to be sure. In my app I don't (at least explicitly) use typePolicies. The query does look similar to what I'm trying to do. The cache writing stuff is where I get lost again; I'm not doing any of that manually either and so I don't know the APIs.
Does that help at all, or what would you like me to do?
(edit) I just read the ticket, and it definitely sounds right to me! Curious about the order of the subtypes.
@tremby that helps! I have a few other priorities at the moment but should be able to circle back to look at that failing test again next week. Thanks for confirming my suspicions :)