Relay使用什么来决定在变异响应中包含哪些outputFields？

Question

I am creating my first React/Relay application by modifying the TODO example. I am to the point where I am adding my own mutation for an object Distributor that has a parameter bookCount. The mutation is called AddBook and simply increases book count by 1. At this point, the mutation executes without error, optimistically increases the bookCount by 1 correctly, but then reverts the model change when it receives the response from the server. I believe this to be because the response from the server mysteriously does not contain any of my specified outputFields.

Here is my mutation:

var GraphQLAddBookMutation = mutationWithClientMutationId({
  name: 'AddBook',
  inputFields: {
  },
  outputFields: {
    distributor: {
      type: GraphQlDistributor,
      resolve: () => getDistributor(),
    },
  },
  mutateAndGetPayload: () => {
    console.log("Trying to mutate.");
    addBook();
    return {};
  },
});

It contains the field 'distributor' in outputFields but no 'distributor' data is included in the graphql response.

The graphql response is:

{
  "data": {
  "addBook": {
    "clientMutationId": "0"
    }
  }
}

I have verified that the mutateAndGetPayload function DOES get called but the distributor resolve function DOES NOT get called.

I would have expected every field in outputFields to be included in the graphql response, and every resolve function within outputFields to be called to populate the appropriate parameters in the response but this is not the case

This is particularly confusing to me because the generated schema.json DOES include any outputFields that I specify in the AddBookPayload:

{
      "kind": "OBJECT",
      "name": "AddBookPayload",
      "description": null,
      "fields": [
        {
          "name": "distributor",
          "description": null,
          "args": [],
          "type": {
            "kind": "OBJECT",
            "name": "Distributor",
            "ofType": null
          },
          "isDeprecated": false,
          "deprecationReason": null
        },
        {
          "name": "clientMutationId",
          "description": null,
          "args": [],
          "type": {
            "kind": "NON_NULL",
            "name": null,
            "ofType": {
              "kind": "SCALAR",
              "name": "String",
              "ofType": null
            }
          },
          "isDeprecated": false,
          "deprecationReason": null
        }
      ],
      "inputFields": null,
      "interfaces": [],
      "enumValues": null,
      "possibleTypes": null
    },

Answer 1

I was finally able to discover the answer to this question myself and the bug in the code so I will include it here for anyone else facing the same concern.

The first crucial thing to understand is the relationship between the FatQuery and the selectionSet. The FatQuery is used by the (web) client to understand what are the possible things that can change after the mutation in question is executed. The client will parse the fat query and its own internal state to see if there is any overlap. If the FatQuery indicates that nothing in the mutation will change anything that the client currently cares about (exists in its internal store), then the client will use GraphQL to indicate that it does not want any data to be returned (if you use all of the default javascript libraries, this will be converted from no-data-returned to only-the-client-mutation-id). This is accomplished by means of the selectionSet. You can view the selection set being requested in GraphQL by looking at the network call to the server in the browser window. In my case, that selection set was empty which was my first clue.

So, long story short, the outputFields included in the mutation response are the intersection of all listed outputFields from the FatQuery and GraphQL client's internal state.

PS There is one other crucial factor that came into play here which is the specifying of the IDs that can be modified. Every bit of data in GraphQL must have a globally unique id. In the TODO app example, that globally unique ID is create as a combination of the type name in question and the 'id' member variable of the type in question. In my case, since I had no 'id' member variable, some confusion ensued. So, if like me, you are experimenting with using the TODO app as the basis of your experiments, do make sure that any type you create has a type-unique member variable named 'id'.