You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Did you search for an existing issue or pull request?
Description
GraphQL subscriptions payload doesn't allow to traverse the data graph
Details
Currently, subscriptions payload only contains an id, mutation_type and _entity, the latest being a JSON field. This makes it hard to manage data on the client side and get full advantage of the apollo cache: apollo can't update the cached data automatically because of the missing __typename in _entity and we have no way to fetch relations as well. A more useful approach would be to have different payload types depending on the subscription, allowing to query deeper the entity being inserted/updated/deleted.
Another solution might be to expose the said entity under the Nodeinterface: this way the payload type is still the same for all subscriptions, but we can query the actual data & resolvers through a fragment inside the node.
Both way, apollo client cache would be correctly updated just by receiving the subscription, eliminating a lot of glue code and refetches on the client side (specially when working with paginated data)
The text was updated successfully, but these errors were encountered:
Thank you ! The PR already makes it really easier to manage updates for simple cases, I'm leaving this open since from what i see nested data are always set to null but definitely a great improvement 🎉
Prerequisites
Description
GraphQL subscriptions payload doesn't allow to traverse the data graph
Details
Currently, subscriptions payload only contains an
id
,mutation_type
and_entity
, the latest being a JSON field. This makes it hard to manage data on the client side and get full advantage of the apollo cache: apollo can't update the cached data automatically because of the missing__typename
in_entity
and we have no way to fetch relations as well. A more useful approach would be to have different payload types depending on the subscription, allowing to query deeper the entity being inserted/updated/deleted.Another solution might be to expose the said entity under the
Node
interface: this way the payload type is still the same for all subscriptions, but we can query the actual data & resolvers through a fragment inside the node.Both way, apollo client cache would be correctly updated just by receiving the subscription, eliminating a lot of glue code and refetches on the client side (specially when working with paginated data)
The text was updated successfully, but these errors were encountered: