-
Notifications
You must be signed in to change notification settings - Fork 2.7k
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
Some UnionType fragments are not triggering the correct loading state for additional queries. #857
Comments
I've tried both with & without addTypename and my id's are globally unique from the relay node interface, versions: [email protected] & [email protected] I'm thinking it is the fragment matching now, I'm not seeing it batch any queries with fragments - #771 suggests there is no matching on unions? |
As long as there is no data there initially, Apollo Client should show the loading state regardless of what type the returned object is going to be. And given __typename, I see no reason why Apollo Client wouldn't be able to figure out which fragment applies. @stubailo what's the status on supporting this simple case of union types from the example above in graphql-anywhere? |
@acorcutt is this still an issue with the latest version? |
This should be fixed with #1483. |
Its only showing a loading state when fetching the 1st fragment from a union, is this related to what is being fixed in #707 or is the loading state looking at the wrong fragment. Data is loaded correctly for all types and re-ordering changes things...
Site is a union...
1st query triggers loading state as expected for either type...
2nd query from child of root triggers loading state when returned type is a Team but not Member...
Re-ordering the fragments triggers loading state when type is a Member but not a Team...
The text was updated successfully, but these errors were encountered: