Commit c600d273 authored by Evan Read's avatar Evan Read

Merge branch 'ld-graphql-docs-mutation-naming-conventions' into 'master'

[Docs] Expand GraphQL mutation naming conventions

See merge request gitlab-org/gitlab!34584
parents cb6f720c fb4e9369
...@@ -717,11 +717,49 @@ will be returned as the result of the mutation. ...@@ -717,11 +717,49 @@ will be returned as the result of the mutation.
### Naming conventions ### Naming conventions
Always provide a consistent GraphQL-name to the mutation, this name is Each mutation must define a `graphql_name`, which is the name of the
used to generate the input types and the field the mutation is mounted mutation in the GraphQL schema.
on. The name should look like `<Resource being modified><Mutation
class name>`, for example the `Mutations::MergeRequests::SetWip` Example:
mutation has GraphQL name `MergeRequestSetWip`.
```ruby
class UserUpdateMutation < BaseMutation
graphql_name 'UserUpdate'
end
```
Our GraphQL mutation names are historically inconsistent, but new
mutation names should follow the convention `'{Resource}{Action}'`
or `'{Resource}{Action}{Attribute}'`.
Mutations that **create** new resources should use the verb `Create`.
Example:
- `CommitCreate`
Mutations that **update** data should use the verb `Update` or a
domain-specific verb like `Set`, `Add`, or `Toggle` if more
appropriate.
Examples:
- `EpicTreeReorder`
- `IssueSetWeight`
- `IssueUpdate`
- `TodoMarkDone`
Mutations that **remove** data should use the verb `Delete` rather than
`Destroy`. Or use a domain-specific verb like `Remove` if more
appropriate.
Examples:
- `AwardEmojiRemove`
- `NoteDelete`
If you need advice for mutation naming, canvass the Slack `#graphql`
channel for feedback.
### Arguments ### Arguments
......
Markdown is supported
0%
or
You are about to add 0 people to the discussion. Proceed with caution.
Finish editing this message first!
Please register or to comment