I'm still not really happy with how the tracker behaves, especially after disconnects. I found out two things:
On a connected event, all stale data is removed from all collections.
On a disconnected event, all subs remain in ready state.
This results in the following: Say you disconnect from your server once your app is sent to background. When you bring your app back to foreground, the connection is reestablished and all docs get removed and then initially added again. During all this, all sub handlers are in ready === true state. Ultimately, this leads to flashing UI and bad UX, since in the normal UI design pattern you pick up any sort of loading / refreshing state from handle.ready().
I already tried to work around to somehow get rid of no 1 (eg. only remove stale docs or something similar). But actually we know that no matter how you implement this part, you need to transfer all the changes / removals that happened during your offline-time from the server. But, of course, in this case, you definitely should be able to inform your user about a reloading state in your UI instead of just removing all docs in front of his eyes and then re-adding them.
This PR implements a more canonical behavior of the ready state of subs when a disconnect happens. In this case, all subs are flagged as not ready. So if you (re)connect, they will simply reload, and all handlers will report that accordingly.
Using this, you can then easily implement an offline-first version of useTracker, that stores tracker results eg. in AsyncStorage, once the corresponding sub is ready and fetches data offline first, if the app is not connected or the sub is not ready yet, and displays live data once the sub is ready. I'm currently testing this on iOS and even on Edge networks this leads to a really responsive UI.
I also tried to put the new LOC marking subs as not-ready in the Meteor.disconnect() method, but of course then you miss disconnections coming from the server side.
Hi all,
I'm still not really happy with how the tracker behaves, especially after disconnects. I found out two things:
connectedevent, all stale data is removed from all collections.disconnectedevent, all subs remain inreadystate.This results in the following: Say you disconnect from your server once your app is sent to background. When you bring your app back to foreground, the connection is reestablished and all docs get removed and then initially added again. During all this, all sub handlers are in
ready === truestate. Ultimately, this leads to flashing UI and bad UX, since in the normal UI design pattern you pick up any sort of loading / refreshing state fromhandle.ready().I already tried to work around to somehow get rid of no 1 (eg. only remove stale docs or something similar). But actually we know that no matter how you implement this part, you need to transfer all the changes / removals that happened during your offline-time from the server. But, of course, in this case, you definitely should be able to inform your user about a reloading state in your UI instead of just removing all docs in front of his eyes and then re-adding them.
This PR implements a more canonical behavior of the ready state of subs when a disconnect happens. In this case, all subs are flagged as not ready. So if you (re)connect, they will simply reload, and all handlers will report that accordingly.
Using this, you can then easily implement an offline-first version of
useTracker, that stores tracker results eg. in AsyncStorage, once the corresponding sub is ready and fetches data offline first, if the app is not connected or the sub is not ready yet, and displays live data once the sub is ready. I'm currently testing this on iOS and even on Edge networks this leads to a really responsive UI.I also tried to put the new LOC marking subs as not-ready in the
Meteor.disconnect()method, but of course then you miss disconnections coming from the server side.