Implement apollo's direct cache access (writeQuery, readQuery)

[lucasavila00]

Let's say I query a list of items and then I query just one item from this list.
I know that the query for one item has the data on the list one but I cannot tell the cache so.

Like apollo, I'd like to be able to do so, but currently the cache is keyed based on the Operation().toKey() method.

The way I thought about doing it is exposing two methods on the client (readQuery and writeQuery) that does this stuff of figuring out the key behind the scenes.

On my fork I've done it and you can check it out.
(the implementation)

My fork is not well mantained and I'm changing stuff all the time so don't assume this is how we'd implement it, I'm only showing it to discuss the surfacing API.

Anyway, having this I can write to the query to expand lists in the cache and mutate fields whenever I want.

What do you think?
Perhaps we should use names like readQueryFromCache and writeQueryToCache for clarity?

Once this is solved I can write a proper PR.

[juicycleff]

@degroote22 that's nice, I think readQueryFromCache and writeQueryToCache seem like a name for this feature. I will wait for @HofmannZ for his input, but you could send a PR so we test this out.

[juicycleff]

I just saw your PR, I will test it out

[HofmannZ]

@degroote22 I think that exposing cache to the query/mutation would be great. I think we should just expose the whole cache rather than just the read/write operations. That's also how Apollo does it. This would also allow us to update the cache after a mutation.

@degroote22 @juicycleff Do you guys agree we should keep that in line with Apollo?

[juicycleff]

@HofmannZ I totally agree to this. I have been looking at the Apollo cache implementation on Android it is the apollo way

[micimize]

I have some related typed state management work in my project that takes advantage of cache normalization to add custom transient state to entities (gist probably not particularly interpret-able out of context)

[micimize]

These methods are exposed in Apollo via the DataProxy interface, which is implemented by the cache and exposed by the client. With Operation.fromOptions and operationName as a getter in #199, the code for this will become a lot simpler.
In the cache:

void writeQuery(QueryOptions options, dynamic data) => write(
      Operation.fromOptions(options).toKey(),
      data,
);
dynamic readQuery(QueryOptions options) => read(
      Operation.fromOptions(options).toKey()
);

In the client:

void writeQuery(QueryOptions options, dynamic data) {
    cache.writeQuery(options, data);
   queryManager.rebroadcastQueries();
};
dynamic readQuery(QueryOptions options) => cache.readQuery(options);

[lucasavila00]

Is there a reason not to implement this after #199 has been merged?

[lucasavila00]

I implemented it on my fork on the query manager itself. I think the cache doesn't need to know about the Operation as how to generate a key.

Client:

  QueryResult readQuery(QueryOptions options) {
    return queryManager.readQuery(options);
  }

  void writeQuery(QueryOptions options, dynamic data) {
    queryManager.writeQuery(options, data);
  }

Query Manager:

  QueryResult readQuery(QueryOptions options) {
    final Operation operation = Operation.fromOptions(options);

    final QueryResult queryResult = QueryResult(
      data: cache.read(operation.toKey()),
      source: QueryResultSource.Cache,
    );

    return queryResult;
  }

  void writeQuery(QueryOptions options, dynamic data) {
    final Operation operation = Operation.fromOptions(options);

    cache.write(
      operation.toKey(),
      data,
    );
    rebroadcastQueries();
  }

[micimize]

@lucasavila00 yeah I was just modeling it on apollo, but I also prefer keeping the cache more generic.
Your implementation looks good to me - would be a welcome PR (on beta)

[lucasavila00]

I plan to submit it with tests.
I'm in a kind of busy week but soon I'll submit it.

[klavs]

As I mentioned in #400 (comment), I think the cache must know about the operation and it's variables to cache the data more intelligently. It is required to understand how each parameterized field was actually queried.

[micimize]

This has been implemented on the cache in v4. Am consolidating the rebroadcasting client methods into #728