Use store until sub is ready

[designmanio]

Use store until sub is ready

[JulianKingman]

In fact it already does that, but it's complicated... When it's online, it persists data with every DDP change. When it's offline, the persisted data is reinserted into minimongo. So the data is there, even after the connection resumes. The difficulty is knowing when to tell your component when the subscription is 'ready', and when to return the Meteor subscription, as opposed to the 'redux subscription' (it's not really a redux subscription, but I mean the redux data that's persisted). If you ignore the ready function entirely, you would probably see the data load into your components as soon as the persisted data restores, but as the subscription is doing stuff, it might be unresponsive. So... I'm not sure where to go from here. Here's the current logic:

const subscribeCached = (store, name, ...args) => {
    // if connected, return normal subscription
    Meteor.waitDdpConnected(() => {
        if (Meteor.ddp.status === 'connected') {
            return Meteor.subscribe(name, ...args);
        }
    });
    // fallback if store not initialized
    if (!store) return Meteor.subscribe(name, ...args);
    // if callback exists, run it
    if(typeof args[args.length - 1] === 'function' && store.getState().ready){
        const callback = _.once(args[args.length - 1]);
        callback();
    }
    // not connected (yet), use offline collection
    return {
        ready: () => {return store.getState().ready || false},
        offline: true,
    };
};

[you-fail-me]

@JulianKingman As far as I understand, now it uses store to actually get data only while offline (only then docs from store get injected to minimongo). If some docs were inserted to minimongo from store, and, later, while having internet connection, the subscription to these docs was stopped (e.g. due to component unmount) the docs would be removed from minimongo, nevertheless there're still such docs in store, wouldn't they? And, when after that you run the subscription again, while having internet connection, you'd have to wait for subscription (from meteor server, not from store) to become ready to show those docs once again. What I was talking about is ability to show docs from store, even online, while having to wait for 'real' docs from meteor server. Do you see some ways to achieve it? Can you think of any major caveats of always pulling data from the store only, ignoring Meteor's ready? I mean smth like that:

const subscribeCached = (store, name, ...args) => {
    if (!store) return Meteor.subscribe(name, ...args);
   
    if(typeof args[args.length - 1] === 'function' && store.getState().ready){
        const callback = _.once(args[args.length - 1]);
        callback();
    }
    const handle = Meteor.subscribe(name, ...args);
    return {
        ready: () => {return store.getState().ready || handle.ready() || false},
        offline: true,
    };
};

In theory that would make us subscribe, but use data only from store, not from 'real' collections, and when the sub is ready data in the store would become updated as well

[JulianKingman]

Actually, it looks like my 'removed' reducer wasn't working... oops! But if it was, then whenever a doc was removed via ddp, it would be removed from the persisted collection. Unfortunately there's no way to know (via the DDP api) whether an object is removed intentionally, or by removing a subscription, or even by disconnection (a problem I avoid by only listening while there's a connection).

[you-fail-me]

So, looks like it requires porting subsmanager

[you-fail-me]

Is there still trouble with the 'REMOVED' reducer in the current version?
Shouldn't it be like

case 'REMOVED':
            if (state[collection][id]) {
                return {
                  ...state,
                    [collection]: _.omit(state[collection], [ id ])
                };
            }
            return state;

?

[JulianKingman]

Something like that. The version on NPM is right, I just pushed it up now.

[you-fail-me]

Btw, sorry for writing here but didn't find any other way to reach you - is that fall-through in switch intentional? Looks like persist/REHYDRATE is dispatched by redux-persist, right? Is it on purpose that in such case we fall through to HARDRESET (no break or return in case, if we don't follow if branch)? Where is HARDRESET used except of this case?

  case 'persist/REHYDRATE':
      if (typeof Meteor.ddp === 'undefined' || Meteor.ddp.status === 'disconnected') {
        return action.payload;
      }
    case 'HARDRESET':
      console.log('hard reset');
      return {};
    default:
      return state;

[JulianKingman]

Good catch. I'll add a return state to the persist action. Basically the HARDRESET is just there in case you need to clear the store out, which I've had to do a couple times while debugging.

[JulianKingman]

The only thing you need to accomplish this is to not wait for handle.ready() for displaying your data. The store will be ready almost instantly, so documents will show up before they come from the server, and when docs are finally finished being added, things should be synced up. I'd recommend somehow showing that documents are offline, though, as elements could change or be removed and a user might not know why.