@@ -59,12 +59,16 @@ viewer. Some typical examples of global fields:
59
59
``` graphql
60
60
# `me` could represent the currently logged in user.
61
61
query getMe {
62
- me { /* ... */ }
62
+ me {
63
+ # ...
64
+ }
63
65
}
64
66
65
67
# `user` represents one of many users in a graph of data.
66
68
query getZuck {
67
- user (id : 4 ) { /* ... */ }
69
+ user (id : 4 ) {
70
+ # ...
71
+ }
68
72
}
69
73
```
70
74
@@ -77,8 +81,8 @@ fetching data from some user object:
77
81
``` graphql
78
82
query getZuck {
79
83
user (id : 4 ) {
80
- id ,
81
- firstName ,
84
+ id
85
+ firstName
82
86
lastName
83
87
}
84
88
}
@@ -90,11 +94,11 @@ nested types. All queries must specify down to scalar fields.
90
94
``` graphql
91
95
query getZuck {
92
96
user (id : 4 ) {
93
- id ,
94
- firstName ,
95
- lastName ,
97
+ id
98
+ firstName
99
+ lastName
96
100
birthday {
97
- month ,
101
+ month
98
102
day
99
103
}
100
104
}
@@ -114,8 +118,8 @@ specific size:
114
118
``` graphql
115
119
{
116
120
user (id : 4 ) {
117
- id ,
118
- name ,
121
+ id
122
+ name
119
123
profilePic (size : 100 )
120
124
}
121
125
}
@@ -126,8 +130,8 @@ Many arguments can exist for a given field:
126
130
``` graphql
127
131
{
128
132
user (id : 4 ) {
129
- id ,
130
- name ,
133
+ id
134
+ name
131
135
profilePic (width : 100 , height : 50 )
132
136
}
133
137
}
@@ -163,9 +167,9 @@ the resulting object will not have duplicate keys:
163
167
``` graphql
164
168
{
165
169
user (id : 4 ) {
166
- id ,
167
- name ,
168
- smallPic : profilePic (size : 64 ),
170
+ id
171
+ name
172
+ smallPic : profilePic (size : 64 )
169
173
bigPic : profilePic (size : 1024 )
170
174
}
171
175
}
@@ -189,7 +193,7 @@ Since the top level of a query is a field, it also can be given an alias:
189
193
``` graphql
190
194
{
191
195
zuck : user (id : 4 ) {
192
- id ,
196
+ id
193
197
name
194
198
}
195
199
}
@@ -269,8 +273,8 @@ of a particular device:
269
273
``` graphql
270
274
query getZuckProfile ($devicePicSize : Int ) {
271
275
user (id : 4 ) {
272
- id ,
273
- name ,
276
+ id
277
+ name
274
278
profilePic (size : $devicePicSize )
275
279
}
276
280
}
@@ -299,13 +303,13 @@ as well as friends of some user:
299
303
query noFragments {
300
304
user (id : 4 ) {
301
305
friends (first : 10 ) {
302
- id ,
303
- name ,
306
+ id
307
+ name
304
308
profilePic (size : 50 )
305
- },
309
+ }
306
310
mutualFriends (first : 10 ) {
307
- id ,
308
- name ,
311
+ id
312
+ name
309
313
profilePic (size : 50 )
310
314
}
311
315
}
@@ -318,14 +322,14 @@ a parent fragment or query.
318
322
``` graphql
319
323
query withFragments {
320
324
user (id : 4 ) {
321
- friends (first : 10 ) { ... friendFields },
325
+ friends (first : 10 ) { ... friendFields }
322
326
mutualFriends (first : 10 ) { ... friendFields }
323
327
}
324
328
}
325
329
326
330
fragment friendFields on User {
327
- id ,
328
- name ,
331
+ id
332
+ name
329
333
profilePic (size : 50 )
330
334
}
331
335
```
@@ -338,17 +342,20 @@ spreads.
338
342
For example:
339
343
340
344
``` graphql
341
- query withNestedFragments
342
- {
345
+ query withNestedFragments {
343
346
user (id : 4 ) {
344
- friends (first : 10 ) { ... friendFields },
345
- mutualFriends (first : 10 ) { ... friendFields }
347
+ friends (first : 10 ) {
348
+ ... friendFields
349
+ }
350
+ mutualFriends (first : 10 ) {
351
+ ... friendFields
352
+ }
346
353
}
347
354
}
348
355
349
356
fragment friendFields on User {
350
- id ,
351
- name ,
357
+ id
358
+ name
352
359
... standardProfilePic
353
360
}
354
361
@@ -378,18 +385,22 @@ For example in this query on the Facebook data model:
378
385
``` graphql
379
386
query FragmentTyping {
380
387
profiles (handles : ["zuck" , " cocacola" ]) {
381
- handle ,
382
- ... userFragment ,
388
+ handle
389
+ ... userFragment
383
390
... pageFragment
384
391
}
385
392
}
386
393
387
394
fragment userFragment on User {
388
- friends { count }
395
+ friends {
396
+ count
397
+ }
389
398
}
390
399
391
400
fragment pageFragment on Page {
392
- likers { count }
401
+ likers {
402
+ count
403
+ }
393
404
}
394
405
```
395
406
@@ -429,14 +440,18 @@ was demonstrated in the `query FragmentTyping` example. We could accomplish the
429
440
same thing using inline fragments.
430
441
431
442
``` graphql
432
- query InlineFragmentTyping {
443
+ query inlineFragmentTyping {
433
444
profiles (handles : ["zuck" , " cocacola" ]) {
434
- handle ,
445
+ handle
435
446
... on User {
436
- friends { count }
437
- },
447
+ friends {
448
+ count
449
+ }
450
+ }
438
451
... on Page {
439
- likers { count }
452
+ likers {
453
+ count
454
+ }
440
455
}
441
456
}
442
457
}
@@ -466,11 +481,11 @@ definition.
466
481
For example, the following query:
467
482
468
483
``` graphql
469
- query HasConditionalFragment ($condition : Boolean ) {
470
- ... MaybeFragment @include (if : $condition )
484
+ query hasConditionalFragment ($condition : Boolean ) {
485
+ ... maybeFragment @include (if : $condition )
471
486
}
472
487
473
- fragment MaybeFragment on Query {
488
+ fragment maybeFragment on Query {
474
489
me {
475
490
name
476
491
}
@@ -480,11 +495,11 @@ fragment MaybeFragment on Query {
480
495
Will have identical runtime behavior as
481
496
482
497
``` graphql
483
- query HasConditionalFragment ($condition : Boolean ) {
484
- ... MaybeFragment
498
+ query hasConditionalFragment ($condition : Boolean ) {
499
+ ... maybeFragment
485
500
}
486
501
487
- fragment MaybeFragment on Query @include (if : $condition ) {
502
+ fragment maybeFragment on Query @include (if : $condition ) {
488
503
me {
489
504
name
490
505
}
0 commit comments