Refactor/union arguments

docs/asciidoc/guides/2.0.0-migration/mutations.adoc

@@ -3,7 +3,7 @@
 
 The most broadly affected area of functionality by the 2.0.0 upgrade are the nested operations of Mutations, to faciliate the mutation of and filtering on relationship properties.
 
-The examples in this section will be based off the following type definitions (which have been migrated over to `@neo4j/graphql` syntax):
+The examples in this section will be based off the following type definitions:
 
 [source, graphql]
 ----

docs/asciidoc/guides/2.0.0-migration/unions.adoc

@@ -0,0 +1,94 @@
+[[rel-migration-unions]]
+= Unions
+
+The structure of input types for union queries and mutations have been changed for user friendliness, and a more consistent API.
+
+The examples in this section will be based off the following type definitions:
+
+[source, graphql]
+----
+type Actor {
+    name: String!
+    actedIn: [Production!]! @relationship(type: "ACTED_IN", direction: OUT)
+}
+
+type Movie {
+    title: String!
+    actors: [Actor!]! @relationship(type: "ACTED_IN", direction: IN)
+}
+
+type Series {
+    title: String!
+    actors: [Actor!]! @relationship(type: "ACTED_IN", direction: IN)
+}
+
+union Production = Movie | Series
+----
+
+Essentially, field names which were previously of template `${unionFieldName}_${concreteType}` (for example, "actedIn_Movie") are now an object, with the field name at the top, and the member types under it.
+
+For example, a Mutation which would have previously been:
+
+[source, graphql]
+----
+mutation {
+    createActors(
+        input: [
+            {
+                name: "Tom Hiddleston"
+                actedIn_Movie: {
+                    create: [
+                        {
+                            title: "The Avengers"
+                        }
+                    ]
+                }
+                actedIn_Series: {
+                    create: [
+                        {
+                            title: "Loki"
+                        }
+                    ]
+                }
+            }
+        ]
+    )
+}
+----
+
+Will now be:
+
+[source, graphql]
+----
+mutation {
+    createActors(
+        input: [
+            {
+                name: "Tom Hiddleston"
+                actedIn: {
+                    Movie: {
+                        create: [
+                            {
+                                node: {
+                                    title: "The Avengers"
+                                }
+                            }
+                        ]
+                    }
+                    Series: {
+                        create: [
+                            {
+                                node: {
+                                    title: "Loki"
+                                }
+                            }
+                        ]
+                    }
+                }
+            }
+        ]
+    )
+}
+----
+
+Note the change in structure for union input, but also the additional `node` level which enables the use of relationship properties. These changes are consistent across all operations, including `where`.

docs/asciidoc/type-definitions/unions-and-interfaces.adoc

@@ -5,93 +5,118 @@ Unions and interfaces are abstract GraphQL types that enable a schema field to r
 
 [[type-definitions-unions-and-interfaces-union-types]]
 == Union Types
-Neo4j GraphQL supports the use of Unions on a `@relationship` field.
 
-=== Example
-The following schema defines a `User` type, that has a relationship(`HAS_CONTENT`), of type `[Content]`. `Content` is of type `union` representing either `Blog` or `Post`.
+The Neo4j GraphQL Library supports the use of unions on relationship fields. For example, the following schema defines a `User` type, that has a relationship `HAS_CONTENT`, of type `[Content]`. `Content` is of type `union` representing either a `Blog` or a `Post`.
 
 [source, graphql]
 ----
 union Content = Blog | Post
 
 type Blog {
-  title: String
-  posts: [Post] @relationship(type: "HAS_POST", direction: OUT)
+    title: String
+    posts: [Post] @relationship(type: "HAS_POST", direction: OUT)
 }
 
 type Post {
-  content: String
+    content: String
 }
 
 type User {
-  name: String
-  content: [Content] @relationship(type: "HAS_CONTENT", direction: OUT)
+    name: String
+    content: [Content] @relationship(type: "HAS_CONTENT", direction: OUT)
 }
 ----
 
+Below you can find some examples of how queries and mutations work with this example.
 
 === Querying a union
-The below query gets the user and their content;
+
+The Neo4j GraphQL Library only returns union members which have inline fragments in your selection set.
+
+For example, the following will return users and only their blogs:
 
 [source, graphql]
 ----
-query GetUsersWithContent {
-  users {
-    name
-    content {
-        ... on Blog {
-            title
-            posts {
-                content
+query GetUsersWithBlogs {
+    users {
+        name
+        content {
+            ... on Blog {
+                title
+                posts {
+                    content
+                }
             }
         }
-        ... on Post {
-            content
+    }
+}
+----
+
+Whilst the query below will return both the blogs and posts of users:
+
+[source, graphql]
+----
+query GetUsersWithAllContent {
+    users {
+        name
+        content {
+            ... on Blog {
+                title
+                posts {
+                    content
+                }
+            }
+            ... on Post {
+                content
+            }
         }
     }
-  }
 }
 ----
 
 === Creating a union
-The below mutation creates the user and their content;
+
+The below mutation creates the user and their content:
 
 [source, graphql]
 ----
 mutation CreateUserAndContent {
-    createUsers(input: [
-        {
-            name: "Dan"
-            content_Blog: {
-                create: [
-                    {
-                        node: {
-                            title: "My Cool Blog"
-                            posts: {
-                                create: [
-                                    {
-                                        node: {
-                                            content: "My Cool Post"
-                                        }
+    createUsers(
+        input: [
+            {
+                name: "Dan"
+                content: {
+                    Blog: {
+                        create: [
+                            {
+                                node: {
+                                    title: "My Cool Blog"
+                                    posts: {
+                                        create: [
+                                            {
+                                                node: {
+                                                    content: "My Cool Post"
+                                                }
+                                            }
+                                        ]
                                     }
-                                ]
+                                }
                             }
-                        }
+                        ]
                     }
-                ]
+                }
             }
+        ]
+    ) {
+        users {
+            name
         }
-    ]
-  ) {
-    users {
-      name
     }
-  }
 }
 
 ----
 
 
 == Interface Types
 
-Using interface types will give you no real database support therefore no; query, update, delete, filter support. But instead used as a language feature to safeguard your schema. Great for when dealing with repetitive or large schemas you can essentially put "The side railings up".
+Using interface types will give you no database support, therefore there is no support for querying, updating, deleting, filtering. But instead used as a language feature to safeguard your schema. Great for when dealing with repetitive or large schemas you can essentially put "The side railings up".