I just released a few helpers to make using flux a bit easier.
Since flux updates itself based on actions sent from the dispatcher, we have to watch collections and fire those actions when it changes. Currently there’s too much boilerplate to do this so I made a few helpers.
// watch collections on Minimongo cache and trigger action on change
trackCollection(Meteor.users, CollectionActions.usersChanged);
trackCollection(Posts, CollectionActions.postsChanged);
as well a helper to just track user data (great for checking if logged in/logged out too)
// watch the logged in user and trigger an action on change
trackViewer(CollectionActions.viewerChanged);
What about adding optional subscription parameter, so it would not spam during !isReady phase.
I dont see any value in incremental spam doing .fetch() for every added document during sub initialization.
Also adding selector and projection parameters could be usefull for more targeted watching.
If we dont want to just feed whole collection to store and sort it there to different actions.
Observe changes above vector and applying to immutable state could be fun too
Yea I think perf. could be improved. I haven’t had a chance to really dig into subscriptions heavily yet… def. need to setup several hundred docs coming in.
If you’re subscribing to 10 posts, is it firing ‘changed’ 10 times as each post comes down the wire? If so maybe we could debounce the action callback.
I think selector option would be nice but the bad part is that parts of your app could not update when you expect them to. In general a data change should just force a re-render for the whole app (or the part listening to that collection. Re-rendering is pretty cheap in react, even more so with Immutable.
And in case of re-sub, when you have 10 docs, 5 should stay, 5 will come and 5 will be removed, it is something like this if I remember correctly
!isReady
5 added -> 15 docs in collection
isReady fired
5 removed -> finaly we have 10 correct docs
So even isReady is fired and simple find() would return all 15 docs from which 5 are already obsolete and should not be there.
Thats why I every time sort and limit on client too, so it does not jump all over template.
Yea i’ll have to look into the race condition more closely. Does this happen when you’re inside the Tracker computation? I originally started out watching the subscription with ready but had the same problem. I didn’t notice that when testing against using tracker and the local collections.
Now when I look at it, I am not exactly sure if isReady have any role at all during resubscribe in tracker.
But during initial load we should not need to re-render till sub is complete.
I am just typing from my bed, should sleep already, if it was not 1000C here
