You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Copy file name to clipboardExpand all lines: site/graphql-js/Tutorial-Mutations.md
+4-4Lines changed: 4 additions & 4 deletions
Original file line number
Diff line number
Diff line change
@@ -12,15 +12,15 @@ Let's say we have a “message of the day” server, where anyone can update the
12
12
13
13
```javascript
14
14
type Mutation {
15
-
setMessage(message:String):Boolean
15
+
setMessage(message:String):String
16
16
}
17
17
18
18
type Query {
19
19
getMessage:String
20
20
}
21
21
```
22
22
23
-
Since `setMessage` doesn't need to return anything useful, we can just return a `Boolean`.
23
+
It's often convenient to have a mutation that maps to a database create or update operation, like `setMessage`, return the same thing that the server stored. That way, if you modify the data on the server, the client can learn about those modifications.
24
24
25
25
Both mutations and queries can be handled by root resolvers, so the root that implements this schema can simply be:
26
26
@@ -29,7 +29,7 @@ var fakeDatabase = {};
29
29
var root = {
30
30
setMessage:function ({message}) {
31
31
fakeDatabase.message= message;
32
-
returntrue;
32
+
returnmessage;
33
33
}
34
34
getMessage:function () {
35
35
returnfakeDatabase.message;
@@ -39,7 +39,7 @@ var root = {
39
39
40
40
You don't need anything more than this to implement mutations. But in many cases, you will find a number of different mutations that all accept the same input parameters. A common example is that creating an object in a database and updating an object in a database often take the same parameters. To make your schema simpler, you can use “input types” for this, by using the `input` keyword instead of the `type` keyword.
41
41
42
-
For example, instead of a single message of the day, let's say we have many messages, indexed in a database by an `ID`, and each message has both a `content` string and an `author` string. We want a mutation API both for creating a new message and for updating an old message. We could use the schema:
42
+
For example, instead of a single message of the day, let's say we have many messages, indexed in a database by the `id` field, and each message has both a `content` string and an `author` string. We want a mutation API both for creating a new message and for updating an old message. We could use the schema:
0 commit comments