The following is the first few sections of a chapter from The Busy Coder's Guide to Android Development, plus headings for the remaining major sections, to give you an idea about the content of the chapter.


Fragments

As an Android developer, you probably have experience with what the Android SDK refers to as fragments. For some of you, this has been a positive experience. For the rest of you… perhaps the experience has not been as nice.

The good news is that GraphQL fragments have nothing to do with Android fragments.

The bad news is that you will have to live with yet another overloaded use of the term “fragment”.

The Role of Fragments

Oddly enough, fragments in GraphQL and Android’s fragments do have a common use case: creating a reusable bit of logic. In the case of Android’s fragments, we are trying to create a reusable bit of UI, to be applied in different ways in different places (e.g., smaller-screen vs. larger-screen layouts).

GraphQL fragments, on the other hand, reuse collections of fields. If there are 2+ places in our GraphQL document where we refer to the same collection of fields, we can define that collection once in a fragment, then reference the fragment where we ordinarily would have the fields themselves.

For example, suppose we have the following document:

query keyStuff {
  allTrips {
    id
    title
  }
}

That is nice and simple. Suppose we further expand the document, to:

query keyStuff {
  allTrips {
    id
    title
  }
}

query moreStuff {
  allTrips {
    id
    title
    priority
    duration
  }
}

We have some duplication, where both the keyStuff and moreStuff operations request the same id and title fields. But, two fields is not that much duplication… until we continue revising the document:

query keyStuff {
  allTrips {
    id
    title
    plans {
      id
      title
    }
  }
}

query moreStuff {
  allTrips {
    id
    title
    priority
    duration
    plans {
      id
      title
      priority
      duration
    }
  }
}

Now we have several axes of duplication:

All that duplication should seem like a code smell… because it is a code smell.

Fortunately, fragments can help eliminate the duplication.

Creating a Fragment

A GraphQL fragment consists of the fragment keyword, a name for the fragment, the data type whose fields we are interested in, and the fields themselves.

For example, we could declare a fragment for those common fields like this:

fragment commonFields on Plan {
  id
  title
}

The on Plan part will constrain where we use this fragment — we can only use it as part of querying for Plan objects, not something else. Plus, tools like GraphiQL can validate that our fragment is referencing actual fields from Plan, instead of containing a typo.

Note that Plan itself is an interface; Trip implements that interface. We will explore interfaces more later in this book. For the time being, take it on faith that Plan defines a bunch of common fields, and Trip implements those fields, as do anything in the plans list.

Using a Fragment

The preview of this section was lost in the sofa cushions.

Fragments, And Your Output

The preview of this section is out seeking fame and fortune as the Dread Pirate Roberts.

Fragments and Your Android Code

The preview of this section was last seen in the Bermuda Triangle.

Where Apollo-Android Generated Code Gets Generated

The preview of this section is off trying to sweet-talk the Khaleesi into providing us with a dragon.