Apply suggestions from code review

Co-authored-by: Benjie <[email protected]>

Author: JoviDeCroock

website/pages/input-unions.mdx

@@ -7,8 +7,8 @@ import { Tabs } from 'nextra/components';
 Some inputs will behave differently depending on what input we choose. Let's look at the case for
 a field named `product`, we can fetch a `Product` by either its `id` or its `name`. Currently we'd
 make a tradeoff for this by introducing two arguments that are both nullable, now if both are passed
-as null we'd have to handle that in code. To fix this the `@oneOf` directive was introduced so we
-can create these input-unions without sacrificing the strictly typed nature of our GraphQL Schema.
+as null (or both non-null) we'd have to handle that in code - the type system wouldn't indicate that exactly one was required. To fix this, the `@oneOf` directive was introduced so we
+can create this "exactly one option" constraint without sacrificing the strictly typed nature of our GraphQL Schema.
 
 <Tabs items={['SDL', 'Code']}>
     <Tabs.Tab>
@@ -19,13 +19,20 @@ const schema = buildSchema(`
     name: String!
   }
 
-  input ProductInput @oneOf {
+  input ProductLocation {
+    aisleNumber: Int!
+    shelfNumber: Int!
+    positionOnShelf: Int!
+  }
+  
+  input ProductSpecifier @oneOf {
     id: ID
     name: String
+    location: ProductLocation
   }
 
   type Query {
-    product(input: ProductInput!): Product
+    product(by: ProductSpecifier!): Product
   }
 `);
 ```
@@ -69,4 +76,5 @@ const schema = new GraphQLSchema({
 </Tabs>
 
 It doesn't matter whether you have 2 or more inputs here, all that matters is
-that your user will have to specify one, and only one, for this input to be valid.
+that your user will have to specify one, and only one, for this input to be valid.
+The values are not limited to scalars, lists and other input object types are also allowed.