Graphql-tag: Issue with multiple queries/mutations in single .graphql file using loader

Created on 11 Apr 2018  路  5Comments  路  Source: apollographql/graphql-tag

The following code is causing some issues with exporting multiple queries/mutations from a single .graphql file.

module.exports = doc;

for (const op of doc.definitions) {
  if (op.kind === "OperationDefinition") {
    if (!op.name) {
      if (operationCount > 1) {
        throw "Query/mutation names are required for a document with multiple definitions";
      } else {
        continue;
      }
    }

    const opName = op.name.value;
    outputCode += `
    module.exports["${opName}"] = oneQuery(doc, "${opName}");        
  }
}

When exporting multiple queries/mutations there are a number of unnecessary properties hanging off of each document.

This is because the root doc is assigned to module.exports
module.exports = doc;
and then is incrementally added to through calls to oneQuery
module.exports["${opName}"] = oneQuery(doc, "${opName}");
which essentially does:
doc["${opName}"] = oneQuery(doc, "${opName}");

The call to oneQuery copies the doc and only overwrites the definitions property. This means that all preceding queries/mutations exist on the new doc created by oneQuery.

Here is an example of what the exported queries may look like:

  • FirstQuery

    • definitions

  • SecondQuery

    • definitions

    • FirstQuery



      • definitions



  • ThirdQuery

    • definitions

    • FirstQuery



      • definitions



    • SecondQuery



      • definitions


      • FirstQuery





        • definitions






The problem is this structure becomes deeply nested and if you deepclone it can cause out of memory exceptions. I didn't encounter this problem until one .graphql file grew in size and we began using Apollo Link State, which does a deep clone on your mutation, removing the @client directive, before executing it.

I don't know if this side-effect exists with purpose but if not I think there should be a shallow clone of doc before assigning it to module.exports.

/label bug

bug

Most helpful comment

I've encountered the same issue. When running any of the mutations below a certain point in my .graphql file, my browser tab completely freezes up and the "out of memory" error can be seen if my console doesn't die first.

All 5 comments

@ryanjsmyth I'm having the same issue .. after some line in the gql doc the queries/mutations just stop working .. can you label this /label bug

Hey @jnwng I think there is a problem with the webpack loader when the gql file gets too big

I've encountered the same issue. When running any of the mutations below a certain point in my .graphql file, my browser tab completely freezes up and the "out of memory" error can be seen if my console doesn't die first.

Heeeey, just see at this beautiful graphic from my dev tools! It really blocks all the shit, can you fix it right now?!
image

Was this page helpful?
0 / 5 - 0 ratings