Allow cache.{read,write}Query to take options.id.

[benjamn]

Writing data to a specific entity object in the cache should not require the additional boilerplate of creating a named fragment with a type condition.

All the cache really cares about is the top-level selection set of the query or fragment used to read or write data, and from that perspective queries are an almost perfect substitute for fragments, in almost all cases.

In other words, this code

cache.writeFragment({
  id,
  fragment: gql`
    fragment UnnecessaryFragmentName on UnnecessaryType {
      firstName
      lastName
    }
  `,
  data: {
    __typename: "UnnecessaryType",
    firstName,
    lastName,
  },
});

can now be written as just

cache.writeQuery({
  id, // This option is new!
  query: gql`{ firstName lastName }`,
  data: { firstName, lastName },
});

Once you get used to using queries instead of fragments, you may begin to wonder why you ever thought fragments were a good idea. To save you some existential turmoil: fragments are still a good idea if you really need their type condition behavior (that is, if you want the fragment to match only when the on SomeType condition holds), but otherwise passing options.id and options.query to cache.readQuery or cache.writeQuery is a lot simpler and just as powerful.

If you need further convincing, the cache.readFragment and cache.writeFragment methods actually convert the given options.fragment document to a query document (using getFragmentQueryDocument) which includes the given options.fragment as a ...field. You can skip that needless conversion by just providing options.query to readQuery or writeQuery, and reserving readFragment and writeFragment for the rare cases where fragments actually have advantages over queries.

We are not removing the cache.readFragment and cache.writeFragment methods at this time, though we may consider deprecating them in the future.

As a side benefit, these changes happen to solve our longest outstanding feature request, apollographql/apollo-feature-requests#1, which recently inspired #5866. That's because options.rootId is now always defined when we do this check.

[hwillson]

I ❤️ this @benjamn - looks great, thanks!