Skip to content

Commit f18063c

Browse files
authored
Merge pull request #395 from magento/id-fields
2 parents 25bb317 + 48cfec5 commit f18063c

File tree

1 file changed

+25
-0
lines changed

1 file changed

+25
-0
lines changed
Lines changed: 25 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,25 @@
1+
# ID Fields in Object Types
2+
3+
When a GraphQL Object Type is used to represent an entity that can be referenced by ID, it _should_ follow these best-practices.
4+
5+
## Best Practices
6+
7+
### Do
8+
9+
- Use the `ID` scalar type
10+
- Make the `ID` field non-nullable (syntax: `ID!`)
11+
- Use the field name `id` or `_id`
12+
- Most GraphQL client libs automatically use this field for caching. Any other field name will require manual caching logic on the client
13+
- https://www.apollographql.com/docs/react/caching/cache-configuration/#assigning-unique-identifiers
14+
- https://formidable.com/open-source/urql/docs/graphcache/normalized-caching/#key-generation
15+
- Include an ID field anytime an Object Type _could_ have an ID field
16+
17+
### Do Not
18+
- Include info in the client-facing description describing how the field is encoded/decoded (should be opaque)
19+
- Example: The client shouldn't know if an `ID` is a base64-encoded integer
20+
- Use `String` or `Int` type
21+
- Use duplicate IDs across a concrete type. In other words, if the client wants to produce a cache key, the concatenation of a `__typename` + `id` field should _always_ be unique
22+
23+
## Examples where an ID is not helpful
24+
25+
- Wrapper types, like `SearchResultPageInfo`

0 commit comments

Comments
 (0)