aslagle / reactive-table

A reactive table designed for Meteor
https://atmospherejs.com/aslagle/reactive-table
Other
328 stars 138 forks source link

Server-side test results: 2 annoying bugs about Missing / Leaked Subscriptions #342

Open VansonLeung opened 8 years ago

VansonLeung commented 8 years ago

341

This plugin still does not support (BETA) Server-side rendering fluently. Still lots of bugs there & one annoys me most was the strange disappearance of table subscriptions when trying to Subscribe to a Pub which shares the same collection with the Pub the table uses. I could track down a wrong onStop execution of its very own homemade ReactiveTables.Publish function, but I just don't know how to fix that before I gave up & I am forced to use aldeed/meteor-tabular now. I just spent 2 hours to transform all my 7 tables.

(1) The above case is because I implemented View / Edit children buttons into table cells. When I try to view / edit, I still keep the Table template present, while:

(2) I summoned a Modal View for the View / Edit Form. This Modal View is triggered by Iron Router with /:collection_name/view/:id, and then I put the specific subscription into "waitOn".

My subscription is the most simple form:

Meteor.publish("shops", function(_id) {
  return Shops.find(_id);
})

....

.waitOn(() => {
  return Meteor.subscribe("shops", this.params.id)
})

(3) And then, after it successfully fetches the Object from the subscription inside "waitOn", The ReactiveTable.Publish calls onStop() and kills everything in the Table, which is unexpected BUG 1.

The strange case is:

If before doing (2), I do: (4) Trying to change the pages / Filters / Limits, then (2) and (3) will NOT kill the Table items, but the new ReactiveTables.Publish Subscription will NOT call onStop() even after I left the Table page & the Table template should be killed, then if I repeat 1,2,3,4 many times, I will have numerous ReactiveTables.Publish Subscriptions not being killed, which is unexpected BUG 2. I used Mongol to monitor "Subscriptions" and found this behavior.

aslagle commented 8 years ago

Thanks for reporting these. I've left it in beta so far because it hasn't been used widely enough to uncover bugs like this. I'm sorry you had to rewrite your tables :(

I think bug 2 won't be hard to fix, but I'm not sure what could be causing the first bug. The subscription shouldn't be getting stopped if the table template is still rendered. Maybe iron:router is triggering one of the event handlers for some reason.

VansonLeung commented 8 years ago

I also tried in step 2 A. I subscribed a different pub different collection B. I subscribed the same pub but i intend to fetch an empty array from the sub by deliberately poisoning the parameters of this subscription C. I subscribed the same pub and fetched something from the same collection D. I subscribed to a different pub while still fetching from the same collection. I even intended to put unnecessary OR queries to discriminate the .find cursors

A and B does not trigger onStop C does D is my intended workaround as if the bug is related to conflicted subs. It shall work if I separate their pub names and thus sources. Right? Wrong. I thought D shall not trigger onStop but, it does....

That means it is related to conflicted collections ? When it fetch something (not empty array) from the same collection as the table does, the table sub calls onStop. How the hell is the onStop called by some mysterious forces?

But then I dont think this issue is related to iron router.