Cache redirects don't work with interfaces specified by possibleTypes about apollo-feature-requests HOT 2 OPEN

Hi @bluepichu 👋🏻 thanks for opening this issue and thanks for your patience. First, it's totally understandable that a user would expect possibleTypes to factor into a toReference so thanks for this feedback. I believe that updating the default behavior would be a breaking change so I don't see that happening in version 3.x. That said, this is an interesting idea and something we want to explore further 🙏🏻

from apollo-feature-requests.

Thanks for getting back to me!

I think this is definitely worth looking into in the future since the expectation that toReference would work with inheritance is fairly reasonable, but in the meantime I've found a suitable workaround: using the keyFields type policy to customize the cache id. In my example repo, I just made this diff:

diff --git a/src/index.jsx b/src/index.jsx
index afc7a5f..9a2e416 100644
--- a/src/index.jsx
+++ b/src/index.jsx
@@ -127,6 +127,9 @@ const client = new ApolloClient({
             }
           }
         }
+      },
+      Widget: {
+        keyFields: (object) => `Widget:${object.id}`
       }
     },
     possibleTypes: {

Due to the typePolicy inheritance enabled by possibleTypes, FooWidget and BarWidget inherit this keyFields configuration and have cache keys of the form Widget:<id> instead of FooWidget:<id> or BarWidget:<id>. This makes the cache lookups resolve properly, and in my case is sufficient because it's guaranteed that widgets (even those of different types) will never have conflicting ids.

That said, it wasn't particularly obvious from the documentation or the name of the field that you could do this with keyFields; the docs made it sound like this behavior could only be accomplished via dataIdFromObject. I only figured this out because I was poking around in the TS types while checking the type of something unrelated. It might be good to add an example of using a function to fully specify the cache key in this section of the documentation, and might even be worth considering changing the name of the field in a future version since in this case the function generates the cache key directly rather than having anything in particular to do with fields of the object as the name suggests.

from apollo-feature-requests.