Full support for union/interface types

[nevir]

Full support for union/interface types

[jamesreggio]

Hi @anthonychung14 — welcome to the project.

I've implemented 95% of the support needed for inline fragments over in #183. If you'd like to begin using it today, I'd suggest you incorporate my branch into a private fork.

(The comment thread on that PR outlines the remaining work needed to get support to 100%, and it's not trivial — it involves having the entire schema available on the client to understand which fragment was matched. This remaining work is mostly in the realm of validation, so it doesn't need to be finished to begin using the branch today.)

[anthonychung14]

I'd be interested in helping with this, though I'm just now getting onboarded with the source code. Our team would benefit greatly from incorporating the improvements you've made with the apollo cache.

Here's how I understand the lib + parsing queries with InlineFragment

• Currently, reading an inline fragment would result in a "failed lookup" since it doesn't know that the fragment needs to be rebuilt (later on?). I'm assuming this is why you mentioned flagging them as union fields.

• It seems like here detects and flattens fragments into the nodeMap. This implies to me that fragments are already (in a sense) being "walked" and they only need to be flagged as unions.
  https://github.com/convoyinc/apollo-cache-hermes/blob/master/src/ParsedQueryNode.ts#L148

• So, would we then want to adjust how _mergeNodes works to complete this flagging?

[jamesreggio]

We've merged support for inline fragments in #183. In the process of implementing it, it became clear that the 'hard' part of this is handling multiple fragments for different types on a given object. This is a common scenario when querying a union type (because you'll likely have one fragment for potential type in the union), but it also crops up when querying object interfaces.

The problem is that without the client being aware of the schema, it doesn't know which type fragments actually matched the object on the server; consequently, it doesn't know which keys to write into the cache, and which to ignore.

@nevir illustrated this problem in #183 (review). Generally, this problem is benign, because it only results in extra nullified keys in the cached object. However, as illustrated in #183 (comment), it can become a little more risky when an object changes types, because you can end up with residual key/value pairs from the prior type fragments.

In the end, this will require something akin to IntrospectionFragmentMatcher from apollo-cache-inmemory to solve. Would be happy to guide anybody who would like to take on this work.