Local Collection not reactive in useTracker in core version 2.5.0

[bratelefant]

If you use the Local Collection (like new Local.Collection("tasks") instead of new Mongo.Collection("tasks")), useTracker will not be triggered on an "added" or "changed" event.

I recreated this behaviour in a fork of the repo meteor-react-native-starter

[bratelefant]

it broke already at release 2.4.0

[jankapunkt]

Seems to be introduced in #111 the big question is, by which part of it.
This also shows, that there was not enough test coverage until that point, otherwise this regression would have been detected.

@ToyboxZach can you help out with this? Maybe we can fix this one together? I'd like to write some tests, would you mind taking a look at the reproduction repo and your former pull request and find out, what change this actually caused?

[bratelefant]

It can be fixed in the local collection by using LocalCols insert and update methods rather than going for minimongos upsert directly.

Eg by turning this

LiveCol.find({}).observe({
        added: async (doc) => {
          LocalCol._collection.upsert(doc);
          storeLocalCol();
        },
....
    };

into this

LiveCol.find({}).observe({
        added: async (doc) => {
          LocalCol.insert(doc); // this informs all observers and triggers useTracker
          storeLocalCol();
        },
....
    };

I'll propose a PR on this. Fixes the issue. But tests for this seem a good idea to make things future proof.

However, as the local collection hasn't changed in #111 , it seems like the trackers behavior did since it now does no longer catch up with modifications on minimongo.

Question is, whether this is a wanted or unwanted behavior.

[jankapunkt]

In any case we definitely need better test coverage for collection reactivity

[bratelefant]

Interestingly, if you try to add a "removed" observer to the LiveCol and try to also make Local Collection reflect removed docs, reactivity fails on removed docs even when using LocalCol.remove().

[jankapunkt]

@bratelefant

Interestingly, if you try to add a "removed" observer to the LiveCol and try to also make Local Collection reflect removed docs, reactivity fails on removed docs even when using LocalCol.remove().

Do I assume correctly, that #123 would require some additions in order to resolve reactivity with remove?

[ToyboxZach]

Yeah sorry, my use cases doesn't utilize any local collections so I wasn't focused on it, I was dependent on the tests to work so there is a good chance I missed triggering the tracker for a lot of cases of local handling

[bratelefant]

Do I assume correctly, that #123 would require some additions in order to resolve reactivity with remove?

Actually not, that's why I'm surprised.

[ToyboxZach]

I think the problem is the original code was using _collection, which was not setup to utilize the new tracker infrastructure, switching to the normal .insert/.update functions will make it work the same way as the remote collections, so I would expect this to work.

Honestly I'm not quite sure what the purpose of the separate Local.Collection is vs just using the Mongo.Collection without a name, which is how normal meteor mongo creates local collections.

My suggestion would be to remove Local.Collections completely and fix any issues that come up in Mongo.Collection where we aren't pushing the right reactivity

[bratelefant]

I guess nameless Mongo collections only live in memory. Local collections use async storage and get updated automatically as soon as ddp is reconnected. I use this to get my app offline first ready.

However, local collections don't recognize removed documents. Guess this is due to the fact that when coming back, initially docs are added (current state from the pub) but nothing "old" is removed. That's why I suggested something like "stale" local documents, that could be old local documents that don't exist on the server anymore and could be removed from the client after a reconnect.

[ToyboxZach]

Hmm that behavior seem like it should instead be an option on meteorrn/minimongo ,

but IMO the better solution would be for each app to handle that, since what I see in LocalCollection doesn't feel like a general solution.

I think a basic implementation would be:

goToBackground(){
const data = collection._collection.db.serialize()
saveDataToDisk(data)

}
comeFromBackground(){
const data = loadDataFromDisk()
collection._collection.db = MemoryDb.deserialize(data);
}

[bratelefant]

I personally consider "offline first" a quite general feature / approach that you might want in your app. Get data from the server, keep it on device, update asap. Hence, it's legit to have this in a package.

@ToyboxZach s example shows how everyone would struggle with all possible situations; for instance this implementation would not work on a disconnect, or what if you reopen the app without a connection?