Rework isFragmentReady API

[n1ru4l]

Is your feature request related to a problem? Please describe.

Today, if multiple fragments select the same fields, but have a different selection set within the individual fields that resolve to an object type or similar, will give false results.

Example:

fragment A on Object {
  a
  b {
    c
  }
}

fragment B on Object {
   a
   b {
     d
   }
}

query Foo {
   a
   ...A @defer
   ...B @defer 
}

Since we only check whether the fields on the query type (Query.a, Query.b) exist within the isFragmentReady helper, even if only the data for the A fragment arrived on the client, the isFragmentReady helper will return true for the check on the B fragment.

Instead,we should focus on a new API that first drops the need for passing the operation document node to isFragmentReady, but also does structural data checks on whether all the data selected within the fragment is satisfied within the object provided.

That will require storing a minimal representation of all the fragment fields (and also subfields) within the TypedDocumentNode / TypedDocumentString.

Describe the solution you'd like

-

Describe alternatives you've considered

No response

Is your feature request related to a problem? Please describe.

No response