Why is dataIdFromObject being deprecated?

[bohdanbirdie]

In the Apollo client v3 the dataIdFromObject is marked as deprecated, but still available for the backward compatibility.

---

In our GraphQL server, every entity could have one of the specific ID keys, eg id, guid, _id, whateverKey, etc.
Previously we were using dataIdFromObject with the logic to select one of the known types of keys from the entity.

Example:

{
  "user": { "guid": "dasd-ed2-d", "name": "User1" },
  "comment": { "id": 123, "text": "My comment" },
}

  dataIdFromObject: (obj) => {
                const { __typename } = obj;
                const idPart = obj.id || obj.guid || obj._id || ....;

                if (!idPart) {
                    return false;
                }
                return `${__typename}:${idPart}`;
            },

So the cache keys would be User:dasd-ed2-d and Comment:123.

At the moment we are migrating to the V3, but since the function is marked as deprecated, eventually, we will have to replace it with the keyFields. And adding the keyFields literally to every type is error-prone and time-consuming.

So, my question - is there actually plans to remove it, and what could be the easy replacement for it in my use case?

[jpvajda]

@bohdanbirdie This is a great question, so let me confirm with the team what the plan is to fully deprecate that API so we can give you clear direction on your migration to V3. cc @hwillson @benjamn

[bohdanbirdie]

Thanks, @jpvajda
Looking forward to it 😉

[hwillson]

👋 @bohdanbirdie - the short answer is that we aren't deprecating dataIdFromObject any time soon.

The long answer is that we think type policies are a safer way to customize cache keys, as outlined in the last few bullet points of our Customizing identifier generation globally docs. The common dataIdFromObject approach is:

• Sensitive to aliasing mistakes
• Usually fails to protect against undefined object properties
• Makes it easy to accidentally use different key fields at different times leading to cache inconsistencies

This being said, there are situations where dataIdFromObject can be easier to use (like yours), which is why we've explored the idea of allowing catch all / dynamic field policies like the policyForField option mentioned in #6808 (comment). As we iterated on that approach, we realized similar functionality could be included in the type policy inheritance features we were working on, so we landed on #7065. With type policy inheritance, you can create a client only super type that your other field policies inherit from, and define things like default key behaviour. If you have a lot of types though this means you'll likely want to either generate your possibleTypes from your schema at build time, or consider using regular expressions to match subtype strings. You can find an example of this in #8756 (comment).

[bohdanbirdie]

@hwillson thanks for the clear answer!

[jpvajda]

I'm going to close this and link to #9817