- adding docs for abstract types in relay resolvers

Reviewed By: captbaritone

Differential Revision: D65181244

fbshipit-source-id: 119462c2aae4793484575df8aeb20c44a727ef80

website/docs/guides/relay-resolvers/defining-types.md

@@ -108,3 +108,55 @@ export type ProfilePicture = { url: string, height: number, width: number };
 :::tip
 Generally weak types are used for creating a namespace for a set of fields that ultimately "belong" to a parent object.
 :::
+
+### Implementing Abstract Types
+
+Relay Resolver types can implement [abstract types](https://relay.dev/docs/glossary/#abstract-type) defined in the graphql schema. Note, these abstract types can
+be defined on your GraphQL server schema OR a [client side schema extension](https://relay.dev/docs/next/guides/client-schema-extensions/).
+
+For example, given the following interface:
+
+```graphql
+# IUser.graphql
+interface IUser {
+  name: String
+}
+```
+
+You could define two (or more) concrete resolver types that implement the IUser interface by adding annotations in the docblock (the same applies for unions).
+<FbInternalOnly>
+Note, support for abstract types is not available for relay resolvers in Flow syntax (yet).
+</FbInternalOnly>
+
+<Tabs
+  groupId="resolver"
+  defaultValue="Docblock"
+  values={fbContent({
+    internal: [
+      {label: 'Docblock', value: 'Docblock'},
+    ],
+    external: [
+      {label: 'Docblock', value: 'Docblock'},
+    ]
+  })}>
+  <TabItem value="Docblock">
+
+
+```tsx
+/**
+ * @RelayResolver BasicUser implements IUser
+ */
+export function BasicUser(id: DataID): BasicUserModel {
+  return { ...BasicUserService.getById(id), name: 'BasicUser1'};
+}
+
+/**
+ * @RelayResolver SpecialUser implements IUser
+ */
+export function SpecialUser(id: DataID): SpecialUserModel {
+  return { ...SpecialUserService.getById(id), name: 'SpecalUser1'};
+}
+```
+
+  </TabItem>
+</Tabs>

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.
 
-## No support for abstract types
-
-Today it is not possible to define an interface or union with multiple concrete types using Relay Resolvers. This is something we would like to support in the future, but have not yet implemented.
-
 ## 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).

website/versioned_docs/version-v18.0.0/guides/relay-resolvers/defining-types.md

@@ -108,3 +108,55 @@ export type ProfilePicture = { url: string, height: number, width: number };
 :::tip
 Generally weak types are used for creating a namespace for a set of fields that ultimately "belong" to a parent object.
 :::
+
+### Implementing Abstract Types
+
+Relay Resolver types can implement [abstract types](https://relay.dev/docs/glossary/#abstract-type) defined in the graphql schema. Note, these abstract types can
+be defined on your GraphQL server schema OR a [client side schema extension](https://relay.dev/docs/next/guides/client-schema-extensions/).
+
+For example, given the following interface:
+
+```graphql
+# IUser.graphql
+interface IUser {
+  name: String
+}
+```
+
+You could define two (or more) concrete resolver types that implement the IUser interface by adding annotations in the docblock (the same applies for unions).
+<FbInternalOnly>
+Note, support for abstract types is not available for relay resolvers in Flow syntax (yet).
+</FbInternalOnly>
+
+<Tabs
+  groupId="resolver"
+  defaultValue="Docblock"
+  values={fbContent({
+    internal: [
+      {label: 'Docblock', value: 'Docblock'},
+    ],
+    external: [
+      {label: 'Docblock', value: 'Docblock'},
+    ]
+  })}>
+  <TabItem value="Docblock">
+
+
+```tsx
+/**
+ * @RelayResolver BasicUser implements IUser
+ */
+export function BasicUser(id: DataID): BasicUserModel {
+  return { ...BasicUserService.getById(id), name: 'BasicUser1'};
+}
+
+/**
+ * @RelayResolver SpecialUser implements IUser
+ */
+export function SpecialUser(id: DataID): SpecialUserModel {
+  return { ...SpecialUserService.getById(id), name: 'SpecalUser1'};
+}
+```
+
+  </TabItem>
+</Tabs>

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.
 
-## No support for abstract types
-
-Today it is not possible to define an interface or union with multiple concrete types using Relay Resolvers. This is something we would like to support in the future, but have not yet implemented.
-
 ## 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).