If there is metadata that you would like stored across write/evict policies, the storage object will store it uniquely for the entity being operated on. A common example of needing a storage option is to compare previous and current field values.
Without a storage option, a write policy would only let you access the current properties of an entity, after the write. Now clients will be able to compare changes to fields which can be helpful in a number of scenarios:
Adds a new
storage
property to policy actions so that they can persist metadata across multiple policy action runs. This storage object is modeled after the Apollo 3 field policies storage option here: https://www.apollographql.com/docs/react/caching/cache-field-behavior/#fieldpolicy-api-reference and serves effectively the same purpose.If there is metadata that you would like stored across write/evict policies, the storage object will store it uniquely for the entity being operated on. A common example of needing a storage option is to compare previous and current field values.
Without a storage option, a write policy would only let you access the current properties of an entity, after the write. Now clients will be able to compare changes to fields which can be helpful in a number of scenarios: