8000 - document semantic nullability support in resolvers · facebook/relay@5600502 · GitHub
[go: up one dir, main page]
More Web Proxy on the site http://driver.im/
Skip to content

Commit 5600502

Browse files
lynnshaoyufacebook-github-bot
lynnshaoyu
authored and
facebook-github-bot
committed
- document semantic nullability support in resolvers
Reviewed By: captbaritone Differential Revision: D65289273 fbshipit-source-id: c5ba813b1d80c57a009619a3c9dbf7b5976cf701
1 parent 34948e3 commit 5600502

File tree

4 files changed

+33
-9
lines changed

4 files changed

+33
-9
lines changed

‎website/docs/guides/relay-resolvers/errors.md

+17-1
Original file line numberDiff line numberDiff line change
@@ -2,7 +2,7 @@
22
id: errors
33
title: "Error Handling"
44
slug: /guides/relay-resolvers/errors/
5-
description: How Relay handles errors throw by resolvers
5+
description: How Relay handles errors thrown by resolvers
66
---
77

88
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({
4646
:::note
4747
[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.
4848
:::
49+
50+
## Support for Semantic Nullability
51+
52+
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.
53+
54+
For example:
55+
```ts
56+
/**
57+
* @RelayResolver RelayExample.semantic_non_null_field: String @semanticNonNull
58+
*/
59+
export function semantic_non_null_field(
60+
model: RelayExampleModel,
61+
): string {
62+
return model.someField ?? 'field was null, this is the default';
63+
}
64+
```

‎website/docs/guides/relay-resolvers/limitations.md

-4
Original file line numberDiff line numberDiff line change
@@ -11,10 +11,6 @@ Relay Resolvers are do have some limitations. Here we will collect a list of kno
1111

1212
In a full GraphQL implementation, resolvers would have access to an `info` argument. This argument is not available in Relay Resolvers today.
1313

14-
## All fields must be nullable
15-
16-
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).
17-
1814
## Not all GraphQL constructs are supported
1915

2016
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.

‎website/versioned_docs/version-v18.0.0/guides/relay-resolvers/errors.md

+16
Original file line numberDiff line numberDiff line change
@@ -46,3 +46,19 @@ const environment = new Environment({
4646
:::note
4747
[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.
4848
:::
49+
50+
## Support for Semantic Nullability
51+
52+
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.
53+
54+
For example:
55+
```ts
56+
/**
57+
* @RelayResolver RelayExample.semantic_non_null_field: String @semanticNonNull
58+
*/
59+
export function semantic_non_null_field(
60+
model: RelayExampleModel,
61+
): string {
62+
return model.someField ?? 'field was null, this is the default';
63+
}
64+
```

‎website/versioned_docs/version-v18.0.0/guides/relay-resolvers/limitations.md

-4
Original file line numberDiff line numberDiff line change
@@ -11,10 +11,6 @@ Relay Resolvers are do have some limitations. Here we will collect a list of kno
1111

1212
In a full GraphQL implementation, resolvers would have access to an `info` argument. This argument is not available in Relay Resolvers today.
1313

14-
## All fields must be nullable
15-
16-
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).
17-
1814
## Not all GraphQL constructs are supported
1915

2016
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.

0 commit comments

Comments
 (0)
0