tmeasday / meteor-router

MIT License
366 stars 76 forks source link

Meteor.call within beforeRouting() #84

Closed cdcme closed 11 years ago

cdcme commented 11 years ago

I'm doing two Meteor.calls within Router.beforeRouting() and I console.log the results. I noticed that in the console, it seems like they're both being fired non-stop instead of just once. To reproduce, do something like:

Meteor.Router.beforeRouting = function(context) {
  if (context.params.someParam) {
    Meteor.call('someFunc1', arg1, function(err, result) {
      if (err) {
        console.log(err);
      } else {
        console.log(result);
      }
    });
  }
};

If you look in console, you should see a steady stream of results flying by.

tmeasday commented 11 years ago

That's a weird one. Are your routes chaging all the time?

Can you link me to a project reproducing the problem on github?

cdcme commented 11 years ago

I'm not sure what you mean by changing all the time but I don't think so. It's a private repo, so I'll make you a contributor so you can take a look. The file is https://github.com/carlodicelico/v2/blob/master/client/lib/routes.coffee.

Yeah, it's really strange. I can understand beforeRouting() firing more than once - say, between one and five times, but it just keeps firing non-stop.

I mean, since I'm setting a per-user token via a Meteor.call(), I'd ideally like it to fire just once but it would be okay if it fired 3 to 5 times - just not indefinitely.

UPDATE: It seems to be related to the collection update operation that I'm doing in the callback that fires when Meteor.call('getTBCreds') returns. When I comment it out and replace it with a simple console.log(), it all just fires once.

tmeasday commented 11 years ago

Mmm. Yeah, no idea why it's happening.

But I would say that beforeRouting isn't intended to be used the way you have. I think you should use a filter to achieve what you've done there.

cdcme commented 11 years ago

Yeah, I initially thought a filter would be perfect but because in meteor-router's Readme it states that filters work like after_filter, then I decided to treat beforeRouting like Rails before_filter because that's what I think I really need - an after_filter would be too late. I know the whole timing of routing and rendering is probably WAY different than in Rails but using Rails as a mental model, I figured an after_filter in Rails would be too late for what I'm doing, so it would probably be to late in Meteor, as well. That may be a mistaken assumption on my part.

Thanks, anyway, I'll keep tinkering with it. It seems the only thing holding up progress is the one line where I make a call to update the collection. The rest works perfectly. Have you tested updating a collection from within beforeRouting? I'll set up a separate Meteor project and test beforeRouting with updates and see what I can get going.

cdcme commented 11 years ago

I don't think this is related to meteor-router, after all. I found that if I remove the part of the update query wherein I assign the result from Meteor.call(), it only fires once.