@@ -52,31 +52,35 @@ Note: many examples below will use the query shorthand syntax.
52
52
53
53
## Fields
54
54
55
- A field in the top-level selection set often represents some kind of
56
- information that is globally accessible to your application and the current
57
- viewer. Some typical examples of global fields:
55
+ Fields represent information that is accessible to your application. Some
56
+ typical examples include:
58
57
59
58
``` graphql
60
59
# `me` could represent the currently logged in user.
61
60
query getMe {
62
61
me {
63
- # ...
62
+ name
64
63
}
65
64
}
66
65
67
66
# `user` represents one of many users in a graph of data.
68
67
query getZuck {
69
68
user (id : 4 ) {
70
- # ...
69
+ name
71
70
}
72
71
}
73
72
```
74
73
74
+ In these examples, ` me ` and ` user ` are top-level fields that represent globally
75
+ accessible data and ` name ` is a subfield that represents data on a particular
76
+ object.
77
+
75
78
## Field Selections
76
79
77
- Each field is of a specific type, and the sub-fields must always be explicitly
78
- declared via a field selection, unless it is a scalar. For example, when
79
- fetching data from some user object:
80
+ Each field is of a specific type, and the subfields must always be explicitly
81
+ declared via a field selection, unless the field is a scalar. For example, when
82
+ fetching data from some user object each desired subfield must be requested
83
+ explicitly:
80
84
81
85
``` graphql
82
86
query getZuck {
@@ -88,6 +92,10 @@ query getZuck {
88
92
}
89
93
```
90
94
95
+ In this query, the ` id ` , ` firstname ` , and ` lastname ` fields form the selection
96
+ set of the ` user ` field. The top-level selection set is ` user ` , but could also
97
+ include other top-level fields.
98
+
91
99
Field selections can be further composed to explicitly state all subfields of
92
100
nested types. All queries must specify down to scalar fields.
93
101
0 commit comments