Fragments for reusable selections in GraphQL - Step-by-Step Execution

Concept Flow - Fragments for reusable selections

Define Fragment

↓

Use Fragment in Query

↓

GraphQL Server Expands Fragment

↓

Execute Query with Expanded Fields

↓

Return Data with Reused Fields

You first define a fragment with reusable fields, then include it in queries. The server replaces the fragment with its fields before running the query.

Execution Sample

GraphQL

fragment userFields on User {
  id
  name
  email
}

query getUsers {
  users {
    ...userFields
  }
}

Defines a fragment 'userFields' with common user fields, then uses it inside a query to fetch users with those fields.

Execution Table

Step	Action	Fragment Expansion	Query Fields	Result Data
1	Define fragment 'userFields'	N/A	N/A	N/A
2	Start query 'getUsers'	N/A	users { ...userFields }	N/A
3	Expand fragment in query	id, name, email	users { id, name, email }	N/A
4	Execute query with expanded fields	N/A	users { id, name, email }	[{"id":1, "name":"Alice", "email":"[e-mail]"}, {"id":2, "name":"Bob", "email":"[e-mail]"}]
5	Return data to client	N/A	N/A	Same as step 4

💡 Query completes after expanding fragments and fetching requested fields.

Variable Tracker

Variable	Start	After Step 3	After Step 4	Final
Fragment 'userFields'	Not defined	Defined with id, name, email	Used in query expansion	Used in final query
Query fields	users { ...userFields }	users { id, name, email }	Executed with these fields	Returned data matches these fields
Result data	Empty	Empty	[{"id":1, "name":"Alice", "email":"[e-mail]"}, {"id":2, "name":"Bob", "email":"[e-mail]"}]	Returned to client

Key Moments - 2 Insights

Why do we define fragments separately instead of writing fields directly in the query?

Fragments let you reuse the same set of fields in many places, avoiding repetition and mistakes. See step 1 and 3 in the execution_table where the fragment is defined once and then expanded.

Does the server send the fragment name in the response?

No, the server replaces the fragment with its fields before running the query, so the response only contains the actual data fields. See step 4 and 5 where the result data has fields but no fragment names.

Visual Quiz - 3 Questions

Look at the execution_table, at which step is the fragment expanded into actual fields?

A Step 2

B Step 3

C Step 4

D Step 5

💡 Hint

Check the 'Fragment Expansion' column in the execution_table.

According to variable_tracker, what fields does the fragment 'userFields' include after step 3?

A name, email

B id, name

C id, name, email

D id, email

💡 Hint

Look at the 'Fragment 'userFields'' row under 'After Step 3' in variable_tracker.

If you add a new field 'age' to the fragment, what changes in the execution_table?

A Step 3's Fragment Expansion will include 'age'

B Step 4's Result Data will exclude 'age'

C Step 2 will show 'age' in query fields

D No changes anywhere

💡 Hint

Fragments control which fields are expanded in step 3.

Concept Snapshot

Fragments let you define reusable sets of fields.
Syntax: fragment Name on Type { fields }
Use with ...Name inside queries.
Server replaces fragments with fields before execution.
Helps avoid repeating field lists in multiple queries.

Full Transcript

Fragments in GraphQL are reusable pieces of field selections. You define a fragment with a name and a set of fields on a type. Then, inside queries, you use the fragment by prefixing its name with three dots. The GraphQL server expands these fragments by replacing them with their field lists before running the query. This way, you avoid repeating the same fields in many queries. The response only contains the actual data fields, not the fragment names. This makes queries cleaner and easier to maintain.

Practice

1. What is the main purpose of using fragments in GraphQL queries?

easy

A. To define variables for queries

B. To reuse a set of fields in multiple queries or parts of a query

C. To create mutations for updating data

D. To sort the results of a query

Solution

1. Step 1: Understand what fragments do

   Fragments allow you to save a group of fields so you can use them repeatedly without rewriting.

2. Step 2: Identify the purpose in queries

   This helps keep queries clean and avoids repetition by reusing the same field selections.

3. Final Answer:

   To reuse a set of fields in multiple queries or parts of a query -> Option B

4. Quick Check:

   Fragments = reusable fields [OK]

Hint: Fragments save repeated fields for reuse in queries [OK]

Common Mistakes:

• Confusing fragments with variables
• Thinking fragments sort or filter data
• Using fragments to define mutations

2. Which of the following is the correct syntax to include a fragment named UserDetails inside a query?

easy

A. ...UserDetails

B. fragment UserDetails {...}

C. ...UserDetails()

D. include UserDetails

Solution

1. Step 1: Recall how to use fragments in queries

   To include a fragment, you use three dots followed by the fragment name without parentheses.

2. Step 2: Match the correct syntax

   ...UserDetails uses ...UserDetails, which is the correct way to include the fragment.

3. Final Answer:

   ...UserDetails -> Option A

4. Quick Check:

   Include fragment = ...FragmentName [OK]

Hint: Use three dots plus fragment name to include it [OK]

Common Mistakes:

• Adding parentheses after fragment name
• Using 'include' keyword instead of ...
• Trying to redefine fragment inside query

3. Given the fragment definition:

fragment UserInfo on User { id name }

and the query:

{ user(id: 1) { ...UserInfo email } }

What fields will the query return?

medium

A. { id, email }

B. { id, name }

C. { id, name, email }

D. { email }

Solution

1. Step 1: Understand fragment fields

   The fragment UserInfo includes id and name fields.

2. Step 2: Combine fragment with query fields

   The query requests ...UserInfo plus email, so all three fields are returned.

3. Final Answer:

   { id, name, email } -> Option C

4. Quick Check:

   Fragment fields + extra fields = all returned [OK]

Hint: Fragment fields merge with query fields in results [OK]

Common Mistakes:

• Ignoring fields outside the fragment
• Thinking fragment replaces query fields
• Confusing fragment name with field name

4. Identify the error in this GraphQL query using a fragment:

fragment PostFields on Post { title content } query { posts { ...PostFields() } }

medium

A. Fragment spread should not have parentheses

B. Fragments cannot be used inside queries

C. Fragment name must be lowercase

D. Fragment must include an id field

Solution

1. Step 1: Check fragment spread syntax

   Fragment spreads use three dots plus the fragment name without parentheses.

2. Step 2: Identify the mistake

   The query uses ...PostFields() which incorrectly adds parentheses.

3. Final Answer:

   Fragment spread should not have parentheses -> Option A

4. Quick Check:

   Fragment spread = ...FragmentName without () [OK]

Hint: Do not add parentheses when spreading fragments [OK]

Common Mistakes:

• Adding () after fragment name
• Using lowercase fragment names incorrectly
• Thinking id field is mandatory in fragments

5. You want to fetch a list of books with their title and author details (name and email). You have a fragment:

fragment AuthorInfo on Author { name email }

Which query correctly uses this fragment to get books with author info?

hard

A. query { books { title author { ...AuthorInfo() } } }

B. query { books { title author { AuthorInfo } } }

C. query { books { title author { ...AuthorInfo on Author } } }

D. query { books { title author { ...AuthorInfo } } }

Solution

1. Step 1: Recall correct fragment usage inside nested fields

   Fragments are included with three dots and the fragment name without parentheses or extra keywords.

2. Step 2: Check each option

   query { books { title author { ...AuthorInfo } } } correctly uses ...AuthorInfo inside author field. Others have syntax errors or extra invalid parts.

3. Final Answer:

   query { books { title author { ...AuthorInfo } } } -> Option D

4. Quick Check:

   Use ...FragmentName inside nested fields [OK]

Hint: Use ...FragmentName exactly inside nested fields [OK]

Common Mistakes:

• Adding parentheses after fragment name
• Using fragment name as a field
• Adding 'on Type' inside fragment spread