Allow persistence and filtering

[wtrocki]

Motivation

Allow queue persistence and filtering.
Support use cases when:

• Queue should only process mutations
• Page was refreshed and queued elements will be removed

Implementation

Using interface that can match local storage or any other platform storage
No extra packages
No change in current behavior (additional object passed to add extra storage and filter )

TODO

More unit tests

[codecov-io]

Codecov Report

Merging #14 into master will not change coverage.
The diff coverage is 100%.

@@          Coverage Diff          @@
##           master    #14   +/-   ##
=====================================
  Coverage     100%   100%           
=====================================
  Files           1      1           
  Lines          25     55   +30     
  Branches        3     12    +9     
=====================================
+ Hits           25     55   +30

Impacted Files	Coverage Δ
src/QueueLink.ts	100% <100%> (ø)	⬆️

---

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update f0d77e4...da060c3. Read the comment docs.

[troyberg]

Thanks for taking the time to try and improve this package, @wtrocki! These 2 features are the final missing pieces for a React Native app I am currently working on. However, when I try testing your branch, my app build begins failing with no error output, which is making it difficult to locate where the conflict is. Just wondering if you might have any clues that would help determine why this is happening. I'd love to test these features out.

[wtrocki]

Thanks for heads up. I haven't checked React Native use case yet. I think I need to improve this PR by:

• Adding debug logging
• Adding apollo client to reschedule operations (rebuild observer chain after restart)
• Test both React Native and Browser use cases

[wtrocki]

I have done some experiments and I think that this PR will change behavior of the package to such extend that it will need to be renamed to not cause issues with current implementations

If you looking for already functional example of the queue with offline support see https://github.com/aerogear/offline-conflict-strategies/tree/master/web/src/sdk/mutations

Just copy this two classes into your app
I'm going to port that to separate apollo-link-offline-queue

[helfer]

Hi @wtrocki, first off, thanks a lot for the PR and my apologies for not responding sooner.

I agree that this is a fairly significant change that might be better off in a separate package.

Alternatively to this implementation for persisting the queue, how about adding public functions that allow getting and setting the content of the queue? That way, any necessary persistence/hydration for orderly shutdowns can be done by an external function.

If the goal is to provide persistence + replay even in the case of unplanned shutdowns, then I think that concern would be best solved in a separate link which persists operations while they're pending, and replays all operations on startup. However, like I commented in another thread, this will not give you the kind of offline support you may expect when using it with Apollo Client, because it's not enough for the link to replay the requests, the store also needs to know about pending operations if their results should be optimistically showed to the user.

[wtrocki]

Fully agree. Closing PR.