Do not require fragments to have `id` in their root in `require-id-when-available`
See original GitHub issueFragments should not be required to include id
field on their root selection set, as this is the query’s responsibility.
This causes a couple of issues:
- Fragments have to include
id
which they may not need at all - If multiple fragments are inlined, all of them need to include the
id
- If
id
is missing on the query and all used fragments, errors are reported for the query and all fragments, making the problem much worse than it is
Consider this example:
fragment UserAvatar {
firstName
lastName
avatar
}
fragment UserManager {
manager {
id
...UserAvatar
}
}
query GetCurrentUser {
me {
id
...UserAvatar
...UserManager
}
}
Both fragments define data requirements of simple UI components - they don’t need the User’s id
to work at all.
This should be added on the query level, as this is the cache’s requirement.
An exception to this is when deeper objects are queried in fragments. Queries don’t know about the fragment internals,
so in this case, it’s fragment’s responsiblity to query the id
.
I’ve made a working change on my fork as we’re using this in a big project: https://github.com/dotansimha/graphql-eslint/compare/master...panrafal:panrafal/dont-require-id-on-fragment-root
Issue Analytics
- State:
- Created 2 years ago
- Reactions:3
- Comments:6 (3 by maintainers)
Top Results From Across the Web
graphql-eslint/README.md at master - GitHub
A GraphQL fragment is only valid when it does not have cycles in fragments usage. recommended,,. no-hashtag-description, Requires to use """ or ...
Read more >Client-side caching - Apollo GraphQL Docs
Where you may not need to manually update the cache: If you use fragments which contain ID's then a query which returns or...
Read more >Menus - Android Developers
If both your activity and fragment(s) declare items for the options menu, they are combined in the UI. The activity's items appear first, ......
Read more >XML Pointer Language (XPointer) - W3C
Although XPointers may be used in many contexts, a very common use of XPointers is expected to be as fragment identifiers in URIs...
Read more >RFC 3986: Uniform Resource Identifier (URI): Generic Syntax
This specification does not require that a URI persists in identifying the same resource over time, though that is a common goal of...
Read more >Top Related Medium Post
No results found
Top Related StackOverflow Question
No results found
Troubleshoot Live Code
Lightrun enables developers to add logs, metrics and snapshots to live code - no restarts or redeploys required.
Start FreeTop Related Reddit Thread
No results found
Top Related Hackernoon Post
No results found
Top Related Tweet
No results found
Top Related Dev.to Post
No results found
Top Related Hashnode Post
No results found
Top GitHub Comments
Hi @panrafal, thanks for the report, this will be tricky to implement, but I’ll work on this to make
graphql-eslint
better 🥳Agree, I think we can consider adding support for parserServices - to allow us to check if a fragment is used and get a list of operations that are using it and then validate it there. It might add some complexity because fragments might be used by other fragments that are used in a query - so this needs some way to “flatten” the query that uses each fragment, and then check if the
id
is used there?