diff options
author | GitLab Bot <gitlab-bot@gitlab.com> | 2021-05-10 18:10:24 +0300 |
---|---|---|
committer | GitLab Bot <gitlab-bot@gitlab.com> | 2021-05-10 18:10:24 +0300 |
commit | bd5eb9f0201cf39ecfb0e754787a2297d5fdf051 (patch) | |
tree | b3770a3806de9bf16a106474e4e8b0b57f4076a3 /doc/development/api_graphql_styleguide.md | |
parent | 0ecdc32a425d18a762fb7723c2063e864065b571 (diff) |
Add latest changes from gitlab-org/gitlab@master
Diffstat (limited to 'doc/development/api_graphql_styleguide.md')
-rw-r--r-- | doc/development/api_graphql_styleguide.md | 25 |
1 files changed, 12 insertions, 13 deletions
diff --git a/doc/development/api_graphql_styleguide.md b/doc/development/api_graphql_styleguide.md index 00b2ac59c14..e8b71e0509a 100644 --- a/doc/development/api_graphql_styleguide.md +++ b/doc/development/api_graphql_styleguide.md @@ -1185,7 +1185,7 @@ are returned as the result of the mutation. The service-oriented architecture in GitLab means that most mutations call a Create, Delete, or Update service, for example `UpdateMergeRequestService`. For Update mutations, you might want to only update one aspect of an object, and thus only need a -_fine-grained_ mutation, for example `MergeRequest::SetWip`. +_fine-grained_ mutation, for example `MergeRequest::SetDraft`. It's acceptable to have both fine-grained mutations and coarse-grained mutations, but be aware that too many fine-grained mutations can lead to organizational challenges in maintainability, code @@ -1281,7 +1281,7 @@ end [input type](https://graphql.org/learn/schema/#input-types). For example, the -[`mergeRequestSetWip` mutation](https://gitlab.com/gitlab-org/gitlab/-/blob/master/app/graphql/mutations/merge_requests/set_wip.rb) +[`mergeRequestSetDraft` mutation](https://gitlab.com/gitlab-org/gitlab/-/blob/master/app/graphql/mutations/merge_requests/set_draft.rb) defines these arguments (some [through inheritance](https://gitlab.com/gitlab-org/gitlab/-/blob/master/app/graphql/mutations/merge_requests/base.rb)): @@ -1294,17 +1294,16 @@ argument :iid, GraphQL::STRING_TYPE, required: true, description: "The IID of the merge request to mutate." -argument :wip, +argument :draft, GraphQL::BOOLEAN_TYPE, required: false, description: <<~DESC - Whether or not to set the merge request as a WIP. - If not passed, the value will be toggled. - DESC + Whether or not to set the merge request as a draft. + DESC ``` These arguments automatically generate an input type called -`MergeRequestSetWipInput` with the 3 arguments we specified and the +`MergeRequestSetDraftInput` with the 3 arguments we specified and the `clientMutationId`. ### Object identifier arguments @@ -1341,7 +1340,7 @@ From here, we can call the service that modifies the resource. The `resolve` method should then return a hash with the same field names as defined on the mutation including an `errors` array. For example, -the `Mutations::MergeRequests::SetWip` defines a `merge_request` +the `Mutations::MergeRequests::SetDraft` defines a `merge_request` field: ```ruby @@ -1379,13 +1378,13 @@ module Types graphql_name "Mutation" - mount_mutation Mutations::MergeRequests::SetWip + mount_mutation Mutations::MergeRequests::SetDraft end end ``` -Generates a field called `mergeRequestSetWip` that -`Mutations::MergeRequests::SetWip` to be resolved. +Generates a field called `mergeRequestSetDraft` that +`Mutations::MergeRequests::SetDraft` to be resolved. ### Authorizing resources @@ -1395,8 +1394,8 @@ To authorize resources inside a mutation, we first provide the required ```ruby module Mutations module MergeRequests - class SetWip < Base - graphql_name 'MergeRequestSetWip' + class SetDraft < Base + graphql_name 'MergeRequestSetDraft' authorize :update_merge_request end |