This is great! Thanks for open-sourcing this, it’s great to have real examples to point new members to. cc @joshowens might like to see this for his open source examples list.
[quote="sergiotapia, post:1, topic:7808"]
If I can bother you guys, I would love some feedback on the source code.
[/quote]
Overall this look great! I didn’t look super hard but I didn’t see any glaring errors 
Here are some suggestions (mostly subjective)
1.
The meteor methods won’t retain the latency compensation if there isn’t a copy on the client. I usually throw these in a both/models/
directory so the client can use it for a stub. If you want to hide the implementation you could just add a stripped down version on the client (called a stub). You can test this out by putting a Meteor._sleepForMs(2000)
before returning the publication cursor.
I like that these are in meteor methods instead of calling update
right in the event handler!
2.
Separating ‘pages’ templates into a pages folder helps me quickly jump to a page. This isn’t a big deal once you’re familiar with the codebase too.
3.
You can make your app more maintainable by abstracting away things that change a lot with things that change very little. This also tends to make it easy to test!
For example, if you make the views very dumb and have them just request data and just call an action that ‘something happened’, it makes it much easier to maintain the view layer. The UI changes a lot while business rules don’t change as much.
Here’s an example that’s held up really well with Blaze (making tons of changes to the Blonk UI)
Views call an action. The Actions are split up into domains and are the middle man. This is imperative (as opposed to flux) but it does let you see exactly what’s being mutated when a user does something (this is a common problem otherwise). You can follow that back to the ‘domain’ object which houses the data getters and the setters (handle action calls).
If you follow the flow by only making a change by calling an action things get easier to follow/debug. If you set a Session variable in an event handler, then it kind of defeats the purpose. Example:
View triggers event (can also pass payload)
Template.SomePage.events({
'click .btn-logout'() {
var id = Meteor.userId();
AppActions.logoutUser(id);
}
});
Actions call domains that are interested
AppActions = {
logoutUser(userId) {
// you could (should) also determine userId here so view does less
AppDomain.onLogoutUser();
ProgressDomain.onLogoutUser(userId);
BarDomain.onLogoutUser(userId);
}
};
Domains respond to calls made by action(s)
// general 'app' related stuff
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);
}
};
anyhow your app codebase looks great! keep up the good work!