question-mark
Stuck on an issue?

Lightrun Answers was designed to reduce the constant googling that comes with debugging 3rd party libraries. It collects links to all the places you might be looking at while hunting down a tough bug.

And, if you’re still stuck at the end, we’re happy to hop on a call to see how we can help out.

Do not require fragments to have `id` in their root in `require-id-when-available`

See original GitHub issue

Fragments 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:closed
  • Created 2 years ago
  • Reactions:3
  • Comments:6 (3 by maintainers)

github_iconTop GitHub Comments

2reactions
B2o5Tcommented, Oct 30, 2021

Hi @panrafal, thanks for the report, this will be tricky to implement, but I’ll work on this to make graphql-eslint better 🥳

1reaction
dotansimhacommented, Oct 31, 2021

Hey @panrafal the tricky part is that we can make this rule smarter without ignoring id field for fragments by checking if the fragment is imported by some operation and at least 1 operation requires his id field.

@dotansimha what do you think?

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?

Read more comments on GitHub >

github_iconTop 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 >

github_iconTop Related Medium Post

No results found

github_iconTop Related StackOverflow Question

No results found

github_iconTroubleshoot Live Code

Lightrun enables developers to add logs, metrics and snapshots to live code - no restarts or redeploys required.
Start Free

github_iconTop Related Reddit Thread

No results found

github_iconTop Related Hackernoon Post

No results found

github_iconTop Related Tweet

No results found

github_iconTop Related Dev.to Post

No results found

github_iconTop Related Hashnode Post

No results found