ApolloClient3: TypePolicy merge readField function always requires a foreignObjOrRef

https://spectrum.chat/apollo/apollo-client/apolloclient3-typepolicies-contexts~0ed2649c-ad4c-4e8a-9a53-9ae52f865e7b

Intended outcome: Be able to use readField in merge functions just like when using it in a read function

Actual outcome: When trying to use it without foreignObjOrRef parameter, the function will always throw

- Network error: Must provide an object or Reference when calling Policies#readField

How to reproduce the issue: Just use the readField function in a merge TypePolicy field

Versions ^3.0.0-beta.43

[bennypowers]

What’s the blessed path for persisting fields in some storage scheme, then?

consider

export const Analysis: TypePolicy = {
  fields: {
    sectionsOpen: {
      merge(prev: SectionsOpen, next: SectionsOpen, { readField }: FieldFunctionOptions): SectionsOpen {
        const id = readField('id') // womp womp, `undefined`
        localStorage.setItem(`sections-open-${id}`, JSON.stringify(next ?? null));
        return next;
      },
      read(prev: SectionsOpen, { readField }: FieldFunctionOptions): SectionsOpen {
        const id = readField('id'); // parent id! yay!
        return (
          prev ??
          JSON.parse(localStorage.getItem(`sections-open-${id}`)) ??
          { /* ...some defaults */ }
        );
      },
    },
  },
};

[ashubham]

@Banou26 You may want to look at this comment in the code though:

https://github.com/apollographql/apollo-client/blob/master/src/cache/inmemory/policies.ts#L549

// Unlike options.readField for read functions, we do not fall
        // back to the current object if no foreignObjOrRef is provided,
        // because it's not clear what the current object should be for
        // merge functions: the (possibly undefined) existing object, or
        // the incoming object? If you think your merge function needs
        // to read sibling fields in order to produce a new value for
        // the current field, you might want to rethink your strategy,
        // because that's a recipe for making merge behavior sensitive
        // to the order in which fields are written into the cache.
        // However, readField(name, ref) is useful for merge functions
        // that need to deduplicate child objects and references.