Create Semantic Nullability Blog Post #1775
Conversation
|
@twof is attempting to deploy a commit to the The GraphQL Foundation Team on Vercel. A member of the Team first needs to authorize it. |
|
The latest updates on your projects. Learn more about Vercel for Git ↗︎
|
|
Love it! Ship whenever you feel this is ready |
|
|
||
| # Semantic Nullability | ||
|
|
||
| > This blog post is directed at application developers using GraphQL. If you are a library author, you should read the more detailed feature spec instead. |
There was a problem hiding this comment.
This should either be a link to said spec or a promise to deliver such (e.g. via follow up blog post)
| name: String! | ||
| age: Int | ||
| posts: [Post] | ||
| } |
There was a problem hiding this comment.
This example (and the previous one) should include a nullable field too, perhaps avatarUrl?
src/pages/blog/2024-08-14-semantic-nullability-for-application-developers.mdx
Outdated
Show resolved
Hide resolved
src/pages/blog/2024-08-14-semantic-nullability-for-application-developers.mdx
Outdated
Show resolved
Hide resolved
src/pages/blog/2024-08-14-semantic-nullability-for-application-developers.mdx
Outdated
Show resolved
Hide resolved
|
|
||
| You should use the modified version of the schema when doing code generation for your frontend application. | ||
|
|
||
| Altering the error handling behavior of your client may be a breaking change if your schema has already adopted semantic nullability, so it's suggested that you select new error handling behavior for your client first. Read the documentation for your specific client for more information. |
There was a problem hiding this comment.
This first sentence is a little confusing (changing client error handling may be a breaking change so you should change client error handling first); could you reword it (e.g. first -> before adopting semantic nullability) or expand it? Also changing client error handling is a breaking change whether or not you’ve adopted semantic nullability, I think? Also it’s somewhat independent of it: you can use one without the other? Perhaps something less specific might work well.
Also most clients don’t have this yet (do they?), should we be surfacing something more actionable?
| ### Server migration | ||
| Once Semantic Nullability has been released, you will be able to start migrating by updating your service to use the most recent version of GraphQL. | ||
|
|
||
| This will open up the option to begin evolving your schema document by document. You can place the document directive `@SemanticNullability` at the top of a file to begin using the new nullability features in that file. The directive will not impact the interpretation of any other files in your schema. |
There was a problem hiding this comment.
| This will open up the option to begin evolving your schema document by document. You can place the document directive `@SemanticNullability` at the top of a file to begin using the new nullability features in that file. The directive will not impact the interpretation of any other files in your schema. | |
| This will open up the option to begin evolving your schema document by document. You can place the document directive `@extendedNullability` at the top of a file to begin using the new nullability features in that file. The directive will not impact the interpretation of any other files in your schema. |
Not 100% sure on which directive name we landed on, but @extendedNullability is used below
There was a problem hiding this comment.
Good catch! The capitalisation is off either way.
src/pages/blog/2024-08-14-semantic-nullability-for-application-developers.mdx
Outdated
Show resolved
Hide resolved
…-developers.mdx Co-authored-by: Benjie <[email protected]>
…-developers.mdx Co-authored-by: Benjie <[email protected]>
…-developers.mdx Co-authored-by: Benjie <[email protected]>
…-developers.mdx Co-authored-by: Benoit 'BoD' Lubek <[email protected]>
No description provided.