diff --git a/website/docs/guides/relay-resolvers/errors.md b/website/docs/guides/relay-resolvers/errors.md index 07b482334ac8e..f3a906d08c532 100644 --- a/website/docs/guides/relay-resolvers/errors.md +++ b/website/docs/guides/relay-resolvers/errors.md @@ -2,7 +2,7 @@ id: errors title: "Error Handling" slug: /guides/relay-resolvers/errors/ -description: How Relay handles errors throw by resolvers +description: How Relay handles errors thrown by resolvers --- Just like GraphQL servers, Relay Resolvers support field-level error handling. If an individual resolver throws an error, when that field is read, Relay will log that error to the environment's user-provided `relayFieldLogger` logger, and the field will become null. @@ -46,3 +46,19 @@ const environment = new Environment({ :::note [Live Resolvers](./live-fields.md) can potentially throw errors when they are first evaluated or when their `.read()` method is called. Both types of errors will be handled identically by Relay. ::: + +## Support for Semantic Nullability + +Relay resolver fields can be specified as [semantically non-null](../../semantic-nullability/) just like server schema fields. Developers can add the directive `@semanticNonNull` in the docblock of a relay resolver in order to indicate that the field is non-nullable in the semantic sense, but that the client should still be prepared to handle errors. + +For example: +```ts +/** + * @RelayResolver RelayExample.semantic_non_null_field: String @semanticNonNull + */ +export function semantic_non_null_field( + model: RelayExampleModel, +): string { + return model.someField ?? 'field was null, this is the default'; +} +``` diff --git a/website/docs/guides/relay-resolvers/limitations.md b/website/docs/guides/relay-resolvers/limitations.md index 38f1df52bfc76..19be2d25be0ed 100644 --- a/website/docs/guides/relay-resolvers/limitations.md +++ b/website/docs/guides/relay-resolvers/limitations.md @@ -11,10 +11,6 @@ Relay Resolvers are do have some limitations. Here we will collect a list of kno In a full GraphQL implementation, resolvers would have access to an `info` argument. This argument is not available in Relay Resolvers today. -## All fields must be nullable - -Today all resolvers must be typed as nullable in order to support coercing errors to null without having to implement null bubbling. In the future we intend Resolvers to support some version of [strict semantic nullability](https://github.com/graphql/graphql-wg/discussions/1410). - ## Not all GraphQL constructs are supported Today Relay Resolvers only support a subset of GraphQL constructs. For example, it's not currently possible to define input types, enums or interfaces using Relay Resolvers. diff --git a/website/versioned_docs/version-v18.0.0/guides/relay-resolvers/errors.md b/website/versioned_docs/version-v18.0.0/guides/relay-resolvers/errors.md index 7afc1d2a99f33..52aa01d2380ff 100644 --- a/website/versioned_docs/version-v18.0.0/guides/relay-resolvers/errors.md +++ b/website/versioned_docs/version-v18.0.0/guides/relay-resolvers/errors.md @@ -46,3 +46,19 @@ const environment = new Environment({ :::note [Live Resolvers](./live-fields.md) can potentially throw errors when they are first evaluated or when their `.read()` method is called. Both types of errors will be handled identically by Relay. ::: + +## Support for Semantic Nullability + +Relay resolver fields can be specified as [semantically non-null](../../semantic-nullability/) just like server schema fields. Developers can add the directive `@semanticNonNull` in the docblock of a relay resolver in order to indicate that the field is non-nullable in the semantic sense, but that the client should still be prepared to handle errors. + +For example: +```ts +/** + * @RelayResolver RelayExample.semantic_non_null_field: String @semanticNonNull + */ +export function semantic_non_null_field( + model: RelayExampleModel, +): string { + return model.someField ?? 'field was null, this is the default'; +} +``` diff --git a/website/versioned_docs/version-v18.0.0/guides/relay-resolvers/limitations.md b/website/versioned_docs/version-v18.0.0/guides/relay-resolvers/limitations.md index 38f1df52bfc76..19be2d25be0ed 100644 --- a/website/versioned_docs/version-v18.0.0/guides/relay-resolvers/limitations.md +++ b/website/versioned_docs/version-v18.0.0/guides/relay-resolvers/limitations.md @@ -11,10 +11,6 @@ Relay Resolvers are do have some limitations. Here we will collect a list of kno In a full GraphQL implementation, resolvers would have access to an `info` argument. This argument is not available in Relay Resolvers today. -## All fields must be nullable - -Today all resolvers must be typed as nullable in order to support coercing errors to null without having to implement null bubbling. In the future we intend Resolvers to support some version of [strict semantic nullability](https://github.com/graphql/graphql-wg/discussions/1410). - ## Not all GraphQL constructs are supported Today Relay Resolvers only support a subset of GraphQL constructs. For example, it's not currently possible to define input types, enums or interfaces using Relay Resolvers.