Partitioner support?

[thebarty]

Hi Johan,

great stuff that we got test-support going! 👍

I am actually running into another problem - within my saas project I am using https://atmospherejs.com/mizzao/partitioner, which is the goto-module to bring tenant-support into meteor. Right now it will not work correctly when previewing emails in the browser and I am working on a fork to support mizzao/partitioner. The question is: does it make sense to invest the extra time for a pull request - would there be a chance that you accept it?

[thebarty]

Hi Johan,

ok, I evaluated this a bit more, and found out that right now Meteor.userId() is NOT available within Template.data()-functions.

Lookback:emails is using Picker.route() to hookup routes for the preview-features. "Picker" is a "server-side"-Router, which still picks up its routes from the client. :-) so what exactly does "server-side" mean in this context? Maybe it is needed for SSR?

Anyway - the most important thing is that that "Picker" looses Meteor.userId() and this.userId, which means that:

• within Template.data() we currently can NOT access Meteor.userId() and this.userId, which also might be needed for some use-cases where the app sends emails to the logged-in user - independently if Partitioner is used, or not
• In order to make Meteor.userId() available within Template.data(), we would have to replace Picker by a FlowRouter-based implementation.

Ok, those are my questions for you:

• Is IronRouter still supported by your package? If yes, how important is it for future versions?
• Why are you using Picker for the preview-routes, does it offer features the FlowRouter does not?
• If you would accept a pull-request - would it be OK, if it was only FlowRouter-based?

I am looking forward to hear your answers. :-)

Thanks a lot for your support! :-)

[johanbrook]

I have no experience in the Partitioner package – what kind of modifications are needed for lookback:emails in order to accommodate support for Partitioner?

Anyway - the most important thing is that that "Picker" looses Meteor.userId() and this.userId

This is expected. You have to provide all data context to email preview routes through passing data, like userIds, via URL parameters. I don't think it's worth it to try to support the currently logged in user via server side email routes.

Is IronRouter still supported by your package? If yes, how important is it for future versions?

It should be, yes. Not important as in "I'm not actively gonna support it at all".

Why are you using Picker for the preview-routes, does it offer features the FlowRouter does not?

Since Picker was a better suitable server side router at the time.

If you would accept a pull-request - would it be OK, if it was only FlowRouter-based?

Summarised: no. I don't see the need for it.

---

Thanks for your thoughts!

[thebarty]

@johanbrook Thanks a lot for your detailed answers! They really helped me figure out the solution.

Good news: NO NEED TO HACK!

If anyone uses the module together with partitioner, simply do something like this in your Template.data(), and call the url with a valid userId.

  const group = Partitioner.getUserGroup(params.query.userId)  // get userId from url-params
  Partitioner.bindGroup(group, () => {
    // fetch data and ONLY pass fetched data to email-template, meaning: do NOT rely 
    // on collection-helpers within the email-template
  })

Thanks to Johan for your help! closed!