-
-
Notifications
You must be signed in to change notification settings - Fork 749
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
Add header to disable null-bubbling #6877
Conversation
Qodana for .NET1 new problem were found
💡 Qodana analysis was run in the pull request mode: only the changed files were checked Contact Qodana teamContact us at [email protected]
|
Codecov ReportAttention: Patch coverage is
Additional details and impacted files@@ Coverage Diff @@
## main #6877 +/- ##
==========================================
+ Coverage 70.04% 70.21% +0.16%
==========================================
Files 2586 2594 +8
Lines 129039 129434 +395
==========================================
+ Hits 90384 90876 +492
+ Misses 38655 38558 -97
Flags with carried forward coverage won't be shown. Click here to find out more. ☔ View full report in Codecov by Sentry. |
This would create a non-spec compliant GraphQL server. We have discussed this in the working group and all agreed that it should not be a default in a GraphQL server. However we could allow it with a header, its the same idea as with the directive ... the client opts into this behaviour. |
@michaelstaib We're in full control of all the clients and can ensure that they can handle it. So the server not being spec-compliant wouldn't be an issue for us. Of course we could also use the current Switching to the current spec proposal with the |
You can adopt the new spec directive, but having it as default is not a good idea. |
However, with a header you can move this into the network layer and no one has to think about it. |
Okay, then I'll switch this from a schema option to a header. |
Can you post a link to the rfc? |
I thought this was the current proposal people were getting behind: graphql/graphql-spec#1065 |
Lets see ... what I can include is a header approach at the moment. I can see that we include the draft with V14 but the new syntax The header we can keep in even after the proposal is merged and is only implemented once in the client network layer. |
Ya, I really dislike it. I prefer Lee's proposal (though I may not fully understand all of the finer details). |
Me too. I'd love ? for nullable and unadorned for non-null (can be null for error). But I guess the new proposal is the most backwards compatible... |
@glen-84 @tobias-tengler in the spec working group we need to make sure that every graphql query that ever was created works when upgrading to a newer GraphQL spec. While when exploring features its good to explore without compromise once you decide for an improvement it must make sure that older queries against the same type system are not breaking. This is especially painful with introspection. If you want to make a breaking change it must be worth the cost of the ecosystem upgrading and breaking lots of applications. |
Do not get hung up on syntax yet. I will do a prototype for V14 tonight ... |
I have started implementing the proposal today ... this will be a high impact change. We will have a new schema option that specifies the NonNull inference. By default we will infer them as strict NonNull types to keep compatibility. Newer servers should opt into the new behavior. services
.AddGraphQLServer()
.ModifyOptions(o => o.NonNullInference = NonNullInferenceKind.SemanticNonNull); With this set all non-null C# types are now inferred as semantic non-null types. In order to explicitly make something strict non-null in this case we need a new annotation. [StrictNonNull]
public string Hello() => "Hello"; New attributes:
Generic Marker Types:
[StrictNonNull<List<StringType>>]
public string Hello() => "Hello"; |
Very exciting! A semantic non-null will only be tagged with the type Product {
name: String @semanticNonNull
} It would be great to also have the proposed ability to just disable null bubbling, since code generation and IDEs won't be able to handle the directive or the new type modifier yet. |
I get that, but Lee's proposal is backwards-compatible – if you don't apply the schema directive ( Even if you added versioning to GraphQL, so that Strict Semantic Nullability could become the default, old queries would simply default to version IMO, the best possible future outcome is what Lee suggests:
For example: type User {
id: ID! # Strict non-null (neither semantic- nor error-null).
username: String? # Nullable, but take note of any field errors (semantic-null vs error-null).
age: Int # Non-nullable (Int or error-null).
} |
8157dc5
to
69e564d
Compare
8a97a79
to
e2d2300
Compare
There will hopefully soon be a prototype for strict nulls (semantic non-null), so this is probably obsolete. Closing. |
No description provided.