Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Incorrect uppercasing used for default values of variables used in query #3290

Closed
sadlerjw-bridgit opened this issue Nov 21, 2023 · 3 comments
Assignees
Labels
bug Generally incorrect behavior needs investigation planned-next Slated to be included in the next release

Comments

@sadlerjw-bridgit
Copy link

Summary

When defining a query using a variable with a default value, if the default value is an input type with a field whose name starts with an uppercase letter, the query's generated code uses the wrong case for that letter when initializing the input type.

For example if an input is defined with a field PREFIX__id, then the generated struct for the input type reformats it to pREFIX__id but the query tries to initialize it using PREFIX__id.

See reproduction steps for a concrete example.

Ideally, the CLI would detect that an ALL-CAPS name is being used and preserve the first-letter capital, but I realize that would likely be a breaking change (and maybe unreliable), so I'd settle for the generated query using the first-letter-lower-cased name :)

Thanks!

Version

CLI 1.7.1

Steps to reproduce the behavior

Create files:

schema/schema.graphqls:

type Query {
    example(
        parameter: Param!
    ) : Response
}

input Param {
    PREFIX__id: String
    PREFIX__name: String
}

type Response {
    something: String
}

queries/query.graphql:

query exampleQuery(
    $parameter: Param = { PREFIX__id : "32" }
) {
    example(parameter: $parameter) {
        something
    }
}

apollo-codegen-config.json

{
  "schemaName" : "ApolloTest",
  "input" : {
    "operationSearchPaths" : [
      "./queries/*.graphql"
    ],
    "schemaSearchPaths" : [
      "./schema/*.graphqls"
    ]
  },
  "output" : {
    "testMocks" : {
      "none" : {
      }
    },
    "schemaTypes" : {
      "path" : "./generated",
      "moduleType" : {
        "other" : {
        }
      }
    },
    "operations" : {
      "inSchemaModule" : {
      }
    }
  }
}

Then run apollo-ios-cli generate, which generates:

generated/Schema/InputObjects/Param.graphql.swift (non-relevant bits snipped out)

public struct Param: InputObject {
  public init(
    pREFIX__id: GraphQLNullable<String> = nil,
    pREFIX__name: GraphQLNullable<String> = nil
  ) {
    __data = InputDict([
      "PREFIX__id": pREFIX__id,
      "PREFIX__name": pREFIX__name
    ])
  }
}

generated/Operations/Queries/ExampleQuery.graphql.swift (snipped again)

public class ExampleQuery: GraphQLQuery {
  public init(parameter: GraphQLNullable<Param> = .init(
    Param(PREFIX__id: "32")
  )) {
    self.parameter = parameter
  }
}

This causes a Swift compilation error since Param's initializer takes a parameter named pREFIX__id but ExampleQuery is trying to give it a parameter PREFIX__id.

Logs

No response

Anything else?

No response

@sadlerjw-bridgit sadlerjw-bridgit added bug Generally incorrect behavior needs investigation labels Nov 21, 2023
@calvincestari
Copy link
Member

Thanks for reporting this @sadlerjw-bridgit. We'll probably get this fixed along with #3249 so they can go out in the same release.

@bignimbus bignimbus added this to the Patch Releases (1.x.x) milestone Nov 30, 2023
@bignimbus bignimbus added the planned-next Slated to be included in the next release label Nov 30, 2023
@BobaFetters
Copy link
Member

This looks to have been resolved by the work done for #3283 and release in version 1.13.0

Copy link
Contributor

github-actions bot commented Jul 2, 2024

Do you have any feedback for the maintainers? Please tell us by taking a one-minute survey. Your responses will help us understand Apollo iOS usage and allow us to serve you better.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug Generally incorrect behavior needs investigation planned-next Slated to be included in the next release
Projects
None yet
Development

No branches or pull requests

4 participants