Apollo-client: Best practices for fragment names

Created on 27 Mar 2017  路  2Comments  路  Source: apollographql/apollo-client

Hi guys.

I have middle project with lot of fragments and I am thinking about best naming convention for fragments.
Currently I can see in the Apollo documentation two types of names.

ComponentName + TypeName

CommentsPage.fragments = {
  comment: gql`
    fragment CommentsPageComment on Comment {
      id
    }
  `,
};

Just ComponentName

VoteButtons.fragments = {
  entry: gql`
    fragment VoteButtons on Entry {
      id
    }
  `,
};

In my project I have always just 1 fragment per component and therefore I am thinking if it is good to use TypeName in the fragment name. If no is it necessary to use Component.fragments? Maybe the better idea will be to use always just Component.fragment instead of Component.fragments. Here is my proposal

VoteButtons.fragment = gql`
  fragment VoteButtons on Entry {
   id
  }
`;

I am really not sure and therefore I will appreciate your thoughts.

Most helpful comment

@seeden That's a great question! I think the decision comes down to what is easiest to understand and maintain:

Fragments are great when you're fetching the same objects and fields in many different queries. You don't want to repeat yourself, so you just use the fragment.

However, there can be such a thing as too many fragments. A common problem in projects with lots of fragments is that the queries become a bit harder to understand. If you don't use any named fragments, it's always immediately clear what data a query fetches. So one of the most important things when using fragments is that their names are meaningful and let you quickly search for that fragment in your codebase.

I think using one fragment per React component is a great choice, because it means the data requirements of that component are declared together with the component. In the first example from GitHunt (i assume) that would mean that it would be better to move that fragment to the Comment component and just call it Comment.

There may be cases where having more than one fragment for a component makes sense, but I haven't come across that yet.

Long story short, I think using one fragment per component and giving it just the component name is a great approach that is very maintainable. 馃憤

All 2 comments

@seeden That's a great question! I think the decision comes down to what is easiest to understand and maintain:

Fragments are great when you're fetching the same objects and fields in many different queries. You don't want to repeat yourself, so you just use the fragment.

However, there can be such a thing as too many fragments. A common problem in projects with lots of fragments is that the queries become a bit harder to understand. If you don't use any named fragments, it's always immediately clear what data a query fetches. So one of the most important things when using fragments is that their names are meaningful and let you quickly search for that fragment in your codebase.

I think using one fragment per React component is a great choice, because it means the data requirements of that component are declared together with the component. In the first example from GitHunt (i assume) that would mean that it would be better to move that fragment to the Comment component and just call it Comment.

There may be cases where having more than one fragment for a component makes sense, but I haven't come across that yet.

Long story short, I think using one fragment per component and giving it just the component name is a great approach that is very maintainable. 馃憤

Thanks @helfer :)

Was this page helpful?
0 / 5 - 0 ratings