Should fieldNormalizer apply also to response keys?

[alfondotnet]

Currently, fieldNormalizer callback will be applied to the keys of object responses that are not part of the query, for example

query {
  @rest()...
  response(id: 1) {
    headers
  }
}

the endpoint response can be:

headers: {
  "Content-Type": "application/json"
}

but due to fieldNormalizer being applied to all keys, having a camelCase fn, for example, would mean that headers ends up becoming:

{
  contentType: "application/json"
}

Is this something that apollo-link-rest should handle?

For now the workaround that I have is override the client in the specific affected <Query>'s with one that doesn't make use of fieldNormalizer

[fbartho]

Selecting the headers in a response as GraphQL isn't really a use case that people have been discussing.

You can probably configure your fieldNameNormalizer to avoid doing that for that key, but honestly, I don't have a great answer for you.

Is this still a concern for you? -- You can disable the fieldNameNormalizer if you don't like this?

[alfondotnet]

The only solution I have thought of is to have two clients, one that applies fieldNameNormalizer and one that doesn't, just for the only two queries where I have this happen.

I could disable it altogether and then just refactor all my code once we ship, but I was just wondering if checking for every property of the response if it's contained in the Query is doable, happy to try a PR if it's desirable.

[alfondotnet]

Closing this, as how I am doing this currently is by passing a fieldNameDenormalizer argument to the @rest directive, which actually supports it, although not documented:

@rest(
        type: "UpdateSubscriberAttributesMutationResponse"
        path: "/developers/me/apps/{args.appId}/subscribers/{args.appUserId}/attributes"
        method: "POST"
        fieldNameDenormalizer: $formSerializer
      )

and then I can call the mutation with:

variables: {
...
 formSerializer: (key: string) => key,
}

This being the perfect solution for me.

Added a PR in: apollographql/apollo-link#1278