feat(graphcache): track types in the data-structure

[JoviDeCroock]

Related to #3470

Summary

This starts tracking a mapping of __typename to a list of entityKey, this enables us to perform operations like invalidate('Todo') which would invalidate every entityKey of the Todo type.

We add non-root typenames when going through the write operation and we clean up entities in the list when we are going through gc runs.

In the future this can instruct us for operations where we can't derive an entity i.e. a create-mutation will invalidate all entities of its own type to ensure we don't run into stale values which leaves us with the scalar return case which won't automatically be handled.

The PR explicitly does not add the updater logic yet so we can see that the explicit API surface does not grow, we support more cases instead.

Set of changes

• Add Map of __typename to a list of keys
• Add support for invalidate('Type') and inavlidate({ __typename: 'Type' })

Questions

Should we support invalidating a full type with field and arguments i.e. invalidate('Todo', 'author') would go through every Todo key and explicitly invalidate the Author field.

Follow-ups

• After this PR we can provide logic where we check the presence of the entity in cahce when there's no updater. When we can't find the entity we perform invalidate({__typename})

[changeset-bot]

🦋 Changeset detected

Latest commit: 8125b32

The changes in this PR will be included in the next version bump.

This PR includes changesets to release 1 package

Name	Type
@urql/exchange-graphcache	Minor

Not sure what this means? Click here to learn what changesets are.

Click here if you're a maintainer who wants to add another changeset to this PR

[JoviDeCroock]

I wonder if we should narrow this down to only supporting invalidate({ __typename: 'Todo' }) as this explicitly can't derive a key nor be a global-id which can be the case with invalidate('x').

EDIT: getting quite sure it's safer to just do { __typename: 'X' } as with global-ids we would other wise have to check whether the resulting key is present in the cache and assume it's a typename when not

[kitten]

I think this could be problematic if people accidentally pass invalidate an entity that happens to be embedded.

This would issue warnings in other places, but if ignored, sometimes, given incomplete fragments for instance, a user could accidentally pass an object that contains no key fields just in that moment.

However, we could allow invalidate('TypeName'), since we can check for types.has(typeName) pretty easily now.

I see below though that we check for Object.keys(x).length. I'm not sure if there's ever a case where someone wants to pass cache.invalidate({ __typename: 'X' }) over just a string?

Might be API-bloat 🤔 Unsure

[kitten]

Nothing that stops us from merging ❤️ All just nit comments and follow-up questions

[kitten]

nit: this could potentially be faster in some cases as a normal object. That's because, while we avoid objects for entity key properties, using objects for anything predictable (field names and type names) should potentially be faster

[kitten]

I think this could be problematic if people accidentally pass invalidate an entity that happens to be embedded.

This would issue warnings in other places, but if ignored, sometimes, given incomplete fragments for instance, a user could accidentally pass an object that contains no key fields just in that moment.

However, we could allow invalidate('TypeName'), since we can check for types.has(typeName) pretty easily now.

I see below though that we check for Object.keys(x).length. I'm not sure if there's ever a case where someone wants to pass cache.invalidate({ __typename: 'X' }) over just a string?

Might be API-bloat 🤔 Unsure