lucasconstantino / apollo-cache-invalidation Goto Github PK

🚨 You need to enable Continuous Integration on Greenkeeper branches of this repository. 🚨

To enable Greenkeeper, you need to make sure that a commit status is reported on all branches. This is required by Greenkeeper because it uses your CI build statuses to figure out when to notify you about breaking changes.

Since we didn’t receive a CI status on the greenkeeper/initial branch, it’s possible that you don’t have CI set up yet. We recommend using Travis CI, but Greenkeeper will work with every other CI service as well.

If you have already set up a CI for this repository, you might need to check how it’s configured. Make sure it is set to run on all new branches. If you don’t want it to run on absolutely every branch, you can whitelist branches starting with greenkeeper/.

Once you have installed and configured CI on this repository correctly, you’ll need to re-trigger Greenkeeper’s initial pull request. To do this, please click the 'fix repo' button on account.greenkeeper.io.

First of all, thank you @lucasconstantino for this library - I'm new to Apollo and the cache invalidation options (or lack thereof) have been the biggest pain point for me so far - your library gives me the kind of capability that I would have expected Apollo to have out of the box.

I struggled to get it to work at first, but with a little debugging and experimentation, I found that in my case, I need each provided path array to start with an item called 'data'. This is a little confusing as I don't see 'data' mentioned in your examples, so I am thought it would be worth asking if I'm missing something and using it wrong, or if this is something that should be documented.

To give more context/detail, my project uses Apollo Angular and has a cache that looks like this:

I have a createTransaction mutation which, as well as adding a new transaction to the database, performs various business logic which affects other transactions and the account (to do with updating running balances etc). After the mutation, I need to invalidate various parts of the cache so that I can guarantee they'll be reloaded from the server next time another page/component tries to display the information. I need to invalidate:

• The balance of each account
• The transactions array inside each account
• The transactions themselves (because the running totals have updated)

Using your library, I've been able to do this using the following code:

const cacheInvalidations = invalidateFields(() => [
  ['data', /^Account.*/, 'balance'],
  ['data', /^Account.*/, 'transactions'],
  ['data', /^Transaction.*/]
]);

return this.createTransactionGQL.mutate({ data: mutationData }, { update: cacheInvalidations }).pipe(
  tap(() => this.apollo.getClient().reFetchObservableQueries())
);

For it to work correctly, it seems I have to:

1. Start each path array with a 'data' item - I can't see any mention of this in the documentation. Is this the expected approach and if so, should it be in the documented examples?
2. Call reFetchObservableQueries() to force the active queries to reload - invalidating the cache doesn't seem to have any effect on watched queries. This method doesn't seem to be mentioned in the Apollo documentation so I'm not sure if this is a sensible approach or not, but it does seem to work and causes watched queries on the page to reload.

When one of my patterns matches a path in the store that has a value of null, I get this error:

apollo.umd.js:1508 TypeError: Cannot convert undefined or null to object
    at Function.keys (<anonymous>)
    at isReference (webpack:///./~/apollo-cache-invalidation/lib/index.js?:42:17)
    at Object.findMatches (webpack:///./~/apollo-cache-invalidation/lib/index.js?:64:9)
    at Object.eval (webpack:///./~/traverse/index.js?:59:22)
    at walker (webpack:///./~/traverse/index.js?:190:22)
    at eval (webpack:///./~/traverse/index.js?:208:29)
    at Array.forEach (native)
    at forEach (webpack:///./~/traverse/index.js?:298:31)
    at walker (webpack:///./~/traverse/index.js?:203:13)
    at eval (webpack:///./~/traverse/index.js?:208:29)

Looks like the problem is that findMatches assumes that this.node is an object and not null.

Hey, I like this library and how readable the code is.

Is there a way the example could be given in a better ? i.e with a query and a mutation...?

I am also still confused with what happyPeople is. I have the idea but the example doesn't seem sufficient.

As of Apollo Client 2.0, there is still a need for this library, but it doesn't seem to invalidate the cache anymore.

I might be able to investigate deeper if I have time, although if it's particularly difficult, I might consider PRing something to Apollo Client itself...