Should help fix #3992. As #3992 (and specifically the reproduction that @OurMajesty provided at https://codesandbox.io/s/q7rkm6y1ow) demonstrates, since the InMemoryCache may return the same object for multiple reads (when the data have not changed), the previousResult is often exactly (===) the same object as newData.result, which was causing the code removed by this commit to return early instead of broadcasting the watch. This early return was unsafe, because the contents of the object may have changed since they were previously broadcast, so we actually do need to report those modifications, even though the object reference is the same. In other words, `previousResult === newData.result` does not imply "nothing has changed," as I mistakenly assumed in this discussion: #3394 (comment) In the longer term, I would like to eliminate the previousResult logic entirely, since it seems redundant now that we can precisely track changes to the store, but for now it's important for backwards compatibility. Specifically, previousResult still provides a way to prefer the previous object if it is structurally identical to the new object, though that preference is moot when `previousResult === newData.result`. The previousResult object should never be used as a basis for skipping broadcasts. Only the application developer can decide whether === object identity means it's safe to skip rendering, likely in the context of a larger design which treats cache results as immutable data. The job of the InMemoryCache is to make no unsound assumptions, and broadcast results whenever they may have changed.

Commits

Commits on Oct 20, 2018

Make InMemoryCache#transformDocument idempotent.

Cache removeConnectionDirectiveFromDocument calls.

Avoid reusing nested defaultQueryInfo arrays.

Avoid fallible previousResult === newData.result check.

Replace fclone with custom deep clone implementation.

Snapshot observableQuery.lastResult to defend against mutation.