Add wishlists in products query as a graph

design-documents/graph-ql/best-practice/nullability.md

@@ -51,7 +51,7 @@ type Query {
    product(id: ID): Product
 }
 
-type Product {
+type ProductInterface {
     id: ID!
     name: String!
     price: Money!
@@ -128,7 +128,7 @@ It very rarely makes sense to have a resource that _can_ have an ID but might no
 IDs are extremely important for caching in most GraphQL clients, so it's worthwhile to be safe here.
 
 ```graphql
-type Product {
+type ProductInterface {
     id: ID! # Rarely makes sense for this to be nullable
 }
 ```
@@ -152,7 +152,7 @@ If you're not dealing with an `id` field or a top-level `Query` field, the most
 #### Example: Parent still usable with field error
 
 ```graphql
-type Product {
+type ProductInterface {
     # Recommended products are not critical data on a product page, and a UI can represent
     # a product safely without related products, so we keep the field nullable
     recommended_products: ProductRecommendations
@@ -162,7 +162,7 @@ type Product {
 #### Example: Parent not usable with field error
 
 ```graphql
-type Product {
+type ProductInterface {
     # A user would not be able to add a product to the cart from the Product
     # details page if this field fails, because it may have required options.
     # We make the field's type non-nullable
@@ -196,7 +196,7 @@ When deciding whether _List items_ should be nullable, the most important questi
 #### Example: Parent not usable if an item in List has an error
 
 ```graphql
-type Product {
+type ProductInterface {
    # Note: The "!" inside of the List ([]) means the list items are non-nullable
    # Making the list items non-nullable guarantees to the client that, if they receive
    # a list of product options, it will be complete/without errors
@@ -207,7 +207,7 @@ type Product {
 #### Example: Parent still usable if an item in List has an error
 
 ```graphql
-type Product {
+type ProductInterface {
     # The absence of a "!" inside the list means that we could fail
     # to fetch a nested field in a related product, and it won't
     # impact our ability to render the rest of the product page

design-documents/graph-ql/coverage/customer/Wishlist.graphqls

@@ -159,7 +159,7 @@ type CreateWishlistOutput {
 
 type DeleteWishlistOutput {
     status: Boolean!
-    wishlists: [Wishlist!]!
+    wishlists: [Wishlist!]! @doc(description: "A customer will always have at least one wishlist")
 }
 
 input WishlistItemCopyInput {
@@ -190,3 +190,13 @@ type StoreConfig {
     maximum_number_of_wishlists: Int @doc(description: "If multiple wish lists are enabled, the maximum number of wish lists the customer can have")
     enable_multiple_wishlists: Boolean @doc(description: "Indicates whether customers can have multiple wish lists.")
 }
+
+#Allow Products to show assigned wishlists
+type ProductInterface {
+    wishlists: [WishlistReference]! @doc(description: "A product can be assigned to multiple wishlists, and by default is not assigned to any wishlist")
+}
+
+type WishlistReference {
+    wishlist_uid: ID!
+    name: String
+}

design-documents/graph-ql/coverage/customer/wishlist.md

@@ -111,3 +111,35 @@ type WishlistItem {
 }
 ```
 This value was previously used for display only, other operations like update or delete are not implemented yet.
+
+## Exposure through product interface
+
+When rendering a product you need to know which wishlists a particular product is assigned to. This is in a way just like categories.
+
+Example:
+``` graphql
+type ProductInterface {
+    wishlists: [WishlistReference]! @doc(description: "A product can be assigned to multiple wishlist of none")
+}
+type WishlistReference {
+   wishlist_uid: ID!
+   name: String
+}
+```
+
+By default a product is not assigned to any wishlist
+
+### Considerations of performance optimizations and usages
+The UI really needs this to render a PDP page or Category with products page and list a dropdown of wishlists of which the product is assigned to.
+It won't need all the data in wishlist for this purpose. However, it would need all the wish lists available and only check the ones that the product belongs to.
+
+The question is: Do we reference the Wishlist and create a minimal type based on what the UI would need or do we just output the whole Wishlist as a true graph would do?
+
+Example:
+``` graphql
+type ProductInterface {
+    wishlists: [Wishlist]! @doc(description: "A product can be assigned to multiple wishlist or now wishlist")
+}
+```
+
+By only going with a small subset of the Wishlist type (`WishlistRerefence`) can improve performance by "cutting the graph" and returning something fit for UI needs rather than loop through all the wishlist.