Issues with Optimistic update of lists based on mutations

[eric-burel]

We currently rely on apollo-link-watched-mutations to update "multi" queries based on update/create/delete mutation.
There are however a few issues. You can check the Starter on the devel branch, eg with example-forms.

• Behaviour is erratic, updates are sometimes detected and done, sometimes not.
• SOLVED (Apollo now handles this out of the box):Update seems to work before the first query, but not after. It seems that Watched Mutation link mess up update instead of handling it, and that Apollo already work correctly out of the box by matching ids of documents in the cache.
• SOLVED using update. Deletion doesn't work after first rendering. It also shows an issue because the Edit form modal is still mounted when deletion appens, so its "withSingle" fails because the document is now deleted. It does not work either after the first query is run. Wateched mutation debug says the cache is up to date but the Datatable is not updated.
• SOLVED using update. For create, it's the reverse. It does not work after SSR, but it works after. In this case Watched Mutation is necessary. This makes sense at least.
• SEEM SOLVED, was due to watched mutations. The Datatable can end up with different "results" and "data[resolverName].results" props after an update and a deletion... while they are the very same object. Probably an unexpected mutation somewhere, maybe in "packages/vulcan-lib/lib/client/apollo-client/updates.js" (functions triggered by watched mutations to compute the new result client side)
• SEEMS SOLVED, was due to watched mutation. The Datatable sometimes stop updating. The polling keeps going but the "useMulti" does not trigger a React update... weird
• SOLVED APollo update function is robust to this issue. Mutation watching does not work after the first render, because no query has been triggered yet, so it can't match mutations and queries. See https://github.com/haytko/apollo-link-watched-mutation/issues/24
• SOVED I could reuse Mingo code. Edge case: "create" mutation will systematically add the item to all lists. This won't respect filters that can exists on some lists. Other mutations are not affected though because they don't create a new item.
• SOLVED same. Ordering may be wrong after create.

Possible solutions:

• use the update function of Apollo mutation functions, and simply get rid of the Watched Mutation link. It will probably work even just after SSR.
• check if there are issues in recent versions of Apollo client? there are sometimes some weird error message in the console
• Use Mingo to check filters when creating an item
• write unit test for "updates" and look for unexpected mutations of the results
• remove update from watched mutation, it seems to work best without watched mutations
• update the DataTable to use "useMulti" hook?

To be tested: https://github.com/ecerroni/apollo-cache-updater
Related: apollographql/apollo-client#3505