Avoid letting defaultDataIdFromObject normalize objects with nullish ids

[benjamn]

Should fix issue #9814, by not allowing objects with id: null or id: void 0 fields to be normalized.

This change mostly affects applications that have not configured keyFields or a custom dataIdFromObject function when creating the InMemoryCache, though I suppose the same confusion could happen when keyFields: ["id"] is explicitly configured and the object.id happens to be null or undefined.

I'm borrowing the "nullish" terminology introduced by the Nullish Coalescing Operator ??, which treats only null and undefined as falsy (not "", 0, or false).

This distinction allows objects with id: "" and id: 0 to be normalized, even though "" and 0 are falsy values. While "" and 0 may be unusual ID values, it's conceivable that an incrementing counter could start at 0, or a string ID could sometimes be the empty string.

You could perhaps argue that objects with id: false also should not be normalized, since false a constant value that's uncommon for IDs, but null and undefined show up due to ordinary GraphQL error behavior, so id: false suggests some actual intention to return a constant value. My mind isn't fully made up about this, but I'm erring on the side of preserving existing behavior.

[alessbell]

Seems reasonable to treat both null and undefined as special cases, given that they can appear due to ordinary GraphQL error behavior as you noted. Should we update any docs, in this PR or a follow-on?

[gurianov-p]

I can see your point about nullish values, but isn’t it technically a breaking change? I think there are perfectly valid use cases where null as ID is appropriate and there are plenty of Apollo users whose code will break once they update to v3.7. For example, we are using null as ID for anonymous users' session data (as opposed to logged in users). For the sake of preserving existing behavior, this change should’ve been introduced in the next major release, not minor.