Hey guys!
I’m putting together a guide for Meteor Best Practices.
Check it out on https://github.com/avalanche1/Meteor-Best-Practices.
I haven’t put much work in it so far - busy building my proj, as I’m sure we all are 
; but I hope eventually we all shall find time to contribute and share knowledge, just like we do on this forum 
.
First PRs are essentially welcome!
Added
you may be interested in this from the guy who co-wrote Discover Meteor and built atmosphere. His unofficial FAQ which I just stumbled upon today during one of my random tangental sessions.
Thank you. I’m already referencing it in ##Misc section of the Guide.
Essentially we cover different topics.
@avalanche1 Would you be interested in adding in this architecture for passing data between the views and handling business logic? This is a pattern i’ve used while building Blonk and a few other prod. apps since then. It makes the app very easy to test and easier to debug. I haven’t written anything yet but would like to write a blog post very soon.
Basic example:
Template.SomePage.events({
'click .btn-logout'() {
var id = Meteor.userId();
AppActions.logoutUser(id);
}
});
AppActions = {
logoutUser(userId) {
// you could (should) also determine userId here so view does less
AppDomain.onLogoutUser();
ProgressDomain.onLogoutUser(userId);
BarDomain.onLogoutUser(userId);
}
};
AppDomain = {
onLogoutUser(userId) {
Meteor.logout();
FlowRouter.go('LoginPage')
}
};
ProgressDomain = {
onLogoutUser(userId) {
// in real life a reactive-dict works better...
Session.set('progress:user:'+userId, null);
}
};
Here’s more detailed info if this piques your interest:
Flux inspired architecture for Blaze (would like your design opinions!)
Thanks for the input!
Seems like a really interesting approach.
Feel free to submit a PR, but this needs a proper guide on implementation.
Cool. I agree it needs some more guidance. I’m planning on writing up a proper spec/guide repo as well as an examples folder very soon. @sashko was also interested in this… so many projects so little time 
I’m also thinking about creating a package with helpers to eliminate boilerplate for actions in case they only pass through data to the domain, such as this:
// shorthand
AppActions = Cosmic.generateActions(
"incrementCounter",
"decrementCounter"
);
I think the MDG position on this is going to be to see what people come up with, then at some point have a big project to try to consolidate all of the best parts of everything into the standard pattern/best practice for building Meteor apps.
Honestly, since you guys are building real apps with this stuff you are probably closer to the ground on what works and what doesn’t, so I don’t know if I will be super helpful in the initial research stages.
Is http://meteorpedia.com/ still a thing? Maybe it would be well suited as central place for this kind of information. Or maybe MDG can start a wiki where the community can add information?
Doesn’t seem to be very active.
Unlike this forum.
Meteorpedida has good info on it. Came in very handy for me recently with load balancing
Added
Added