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

Missing case sensitive type names #75

Closed
sanne-at-visual-nl opened this issue Dec 7, 2020 · 5 comments
Closed

Missing case sensitive type names #75

sanne-at-visual-nl opened this issue Dec 7, 2020 · 5 comments
Assignees

Comments

@sanne-at-visual-nl
Copy link

Input type names are sometimes needed when you use variables declared inside the query. Does the generator have an option to return the case sensitive schema name of a type without the Pascal casing? We rather use nameof() or something similar, and not a magic string.

@Husqvik
Copy link
Owner

Husqvik commented Dec 7, 2020

did you try configuration.JsonPropertyGeneration = JsonPropertyGenerationOption.CaseSensitive or JsonPropertyGenerationOption.Always

then all the data properties will get the attribute that ensures exactly same names as the schema has.

@sanne-at-visual-nl
Copy link
Author

We did, but the fields don't use the type name as name. I'll give an example. We need to use a PersonIDInput type. This will generate a PersonIdInput class.

type PersonIDInput {
  identifier: String!
  type: PersonIDEnum!
}

We can use 3 methods to pass the argument:

  1. as variable (outside)
query ($id: PersonIDInput!) {
  person (id: $id) { lastname }
}
{
  "id": { "identifier": "********", "type": "ID" }
}
  1. as variable (inside)
query ($id: PersonIDInput = { identifier: "********", type: ID }) {
  person (id: $id) { lastname }
}
  1. inline (inside)
query {
  person (id: { identifier: "********", type: ID }) { lastname }
}

In both case 1 and 2, you need to add the type name to the query. This case sensitive name is not available in de generated classes. We could opt to always use case 3 because it doesn't require a type name, but we think that is not a good practice.

@Husqvik
Copy link
Owner

Husqvik commented Dec 7, 2020

Aha, I misunderstood, thought that it's about the property names, not type names.

I'll add generation of a constant to every input object class.

Then next potential next step it could be automatically generate the type name when query parameter created with the type so there is no need to pass it manually.

@Husqvik Husqvik self-assigned this Dec 7, 2020
@sanne-at-visual-nl
Copy link
Author

Thank you for your quick reaction. That last part is indeed the preferred way.

Husqvik added a commit that referenced this issue Dec 9, 2020
auto simple parameter type resolution
@Husqvik
Copy link
Owner

Husqvik commented Dec 9, 2020

added GraphQlTypeName class containing all the type names as constants.

Also added public GraphQlQueryParameter(string name, T value, bool isNullable = true) constructor that resolves built-in scaler types and the input object types automatically. If the type is not resolved an exception is thrown. I still plan to work on that. The old constructor remains because input type can be arrays or nested arrays of not nullable types that most likely cannot be ever resolved automatically.

@Husqvik Husqvik closed this as completed Dec 9, 2020
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

2 participants