Stale docs & skipUpdate for offline first apps

[bratelefant]

Hi all,

since @ToyboxZach s pull request I've been experimenting a bit with my fork of this repo.

I did two things:

1. skipUpdate in useTracker

Works just like in the "web" react useTracker. This really helps to prevent unwanted rerenders triggered by useTracker.

2. Stale docs

In that pull request, on a reconnect, all docs are removed from minimongo cache. In my UI this results in vanishing lists, which then come back, so that usually you would display a full screen loading screen.

Instead, I'd rather display stale data and indicate a "refreshing" state in the UI.

So I replaced the "remove all docs on a reconnect" by "flag all docs as stale". Once a doc is (re)added or updated, the stale flag gets removed. Once a "ready" event is triggered, stale docs are removed from minimongo cache.

Result

Using redux & redux-persist together with AsyncStorage in combination with the above changes allows to build a true offline first app, functioning offline, when restarting off- and online, all without a full screen loading UI, displaying stale data and auto refreshing views when subs are ready.

I don't know if this could be merged into this repo, but at least I wanted to share my ideas ;)

Keep rocking meteor + RN 😀

[ToyboxZach]

Yeah these changes make sense to me.

I know I had issues getting skipUpdate to work at some point, but I cannot remember what was happening.

The going stale definitely seems like a great improvement.

I will be honest though, at this time I do not have the time to manage and update a package/this repo. I cannot give much effort to testing or making sure anything works. I made the package work for me, and just wanted to share my knowledge

[TheRealNate]

Hey there! This is an interesting point. Have you looked into the Meteor web code to see what the behavior is there?

[bratelefant]

The skipUpdate part is almost 1:1 in the web useTracker.

Just tried to find something regarding reconnections in the Meteor repo, but did not succeed yet.

[bratelefant]

How you guys think about an offline-first type of tracker hook? In my production app I have an implementation which works like so:

const {
    data: { messages },
    ready,
  } = useCachedTracker(
    () => {
      if (!user) return { messages: [] };

      const messages = VMessage.find(
        { _userId: user._id },
        { sort: { _createdAt: -1 }, limit: 50 }
      ).fetch();

      return { messages };
    },
    [user._id],
    subReady,
    !connected
  );

Here the signature is almost like the usual useTracker, i.e. first argument is the computation, second dependencies. But now I add in a boolean subReady which is true, if the subscription handler is ready. The last parameter is a boolean that indicates when to fallback to cached data (here: if you are disconnected). An optional parameter (not used in this example) can be used to specify the cache-key.
The ready flag is true as soon as there is a (cached) result available.

Internally the cached tracker stores the computation for the given parameters / dependencies coming from the usual useTracker hook and displays cached data if

1. the connection is gone
2. the sub is not ready yet

This results in scalable offline first fetching of data without too many changes, and faster responding UI if you have slowly responding subs, due to high server response times and/or network bandwidth issues.

[jankapunkt]

Do you think we can wrap this is a companion package?

[bratelefant]

Sounds reasonable, yes. I could prepare a PR when I have some spare time