Skip to content
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

Add documentation for "fuzzy" possibleTypes #10639

Open
alessbell opened this issue Mar 9, 2023 · 7 comments
Open

Add documentation for "fuzzy" possibleTypes #10639

alessbell opened this issue Mar 9, 2023 · 7 comments
Assignees

Comments

@alessbell
Copy link
Member

Issue Description

Adds documentation for the ability to specify "fuzzy" or heuristic subtype matching. See details in #6901.

Link to Reproduction

N/A

Reproduction Steps

No response

@jonnyleeharris
Copy link

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.

@tremby
Copy link

tremby commented Jan 8, 2024

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?

@alessbell
Copy link
Member Author

alessbell commented Jan 24, 2024

@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.

@alessbell
Copy link
Member Author

@tremby I've created an issue #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.

@tremby
Copy link

tremby commented Feb 2, 2024

@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.

@alessbell
Copy link
Member Author

@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 :)

@tremby
Copy link

tremby commented May 21, 2024

Hi @alessbell. Did you find any time to come back to this?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

3 participants