Are additionalTypenames work with graphcache?

[RIP21]

I have the following situation.

• I have Graphcache with Schema Awareness setup
• I fetch a list of all 3rd party Integration
• The user has no integrations, so an empty list is returned.
• Then I move to another page, or stay on the same, and call a mutation that actually adds one Integration
• Return back to / stay on the same page to see that integrations has not been re-fetched
  (At this point I thought that Schema Awareness will help URQL figure out which queries to refetch as it knows what type my integrations is returning despite it returned [])
• I try to work around to explicitly set additionalTypenames: ['Integration'] in my mutation
• It changes nothing

Am I missing something? :)

Also, I'm unsure how keys resolvers are working for interfaces. If I implement keys calculation for the interface will it work on entities that implement this interface? Or I should implement keys resolver for each entity in the app that is impossible to infer from id/_id + __typename combo?

I can elaborate on the example more if needed with the schema example I have :)

BTW, any possibility to refetch not based on type, but rather on query name? It's usually useless and complicates things, but for [] cases it may help if I don't want to use Graphcache :)

[kitten]

No, Graphcache is a normalised cache with the aim to reduce refetches and to share data where possible. (Although with a new addition in the populate exchange this may change in the future, in terms of a slow migration path and alternatives becoming available) But you do have several options:

• manually trigger a refetch. I'll just put this out there since it's intuitive and does the same as additionalTypenames
• add an updater that uses cache.invalidate to remove the cached list and force Graphcache to refetch it
• add an updater that tells Graphcache how to add your new item to the list

There's more details on updaters on this docs page: https://formidable.com/open-source/urql/docs/graphcache/custom-updates/

Interfaces are just common descriptions of fields, hence — like enums — they have no effect on key generation.

On a last part, we'd never offer refetching by query. That'd require us to keep track of all variables that have ever been sent with that queries and those queries themselves, since it makes a difference whether these queries are active or not. Generally no exchange in urql will refetch a query when it's currently not on screen, so that wouldn't yield the behaviour you want, for practical reasons. L

If we'd allow you to pass queries and variables like Apollo, you'd may as well call the client imperatively. This is also a pattern we don't want to encourage though since it introduces coupling between completely separate random queries. One page's mutation shouldn't have to know about all other queries and variables of a given app. That quickly gets out of hand; that's also why in Graphcache the config is centralised. The schema's structure is a better abstraction for caching and updates than queries.

[RIP21]

I love that everything about cache is centralized by design. Passing refetch function would be pain in the ass as it will spread that logic everywhere and will make many components fetching data, they shouldn't fetch, unless I pause them forever in those components that call some mutations that should trigger certain refetches. But that may, again, cause needless eager fetches (not refetches in this case) of data that will never be used by user as he'll never open those pages that need this data, so I assume it's not optimal.
And the best solution indeed is to invalidate certain queries based on fragment or so. As it will make sure only needed data is refetched and lazily.

[RIP21]

Thanks for clarification, now it's clearer :)
I wish tho there is more advanced default cache exchange that is schema aware that will behave exactly the same as original one, but due to schema awareness it can handle empty lists refetches etc without additionalTypenames usage ever. So, less fancy than Graphcache, but still pretty smart :) But without all these partial responses, cache editing etc. that, I guess, make it bigger in size.

[kitten]

That's the thing 😅 Schema awareness and all these other nice features hinge on normalised caching. So in actuality you're asking for an even smarter cache rather than a simpler one.

But I believe if you haven't seen it yet this RFC fits the bill exactly: #964