Learning by building


#1

Hello all.

I am new here and I hope this is in the right place. I have built a little Meteor app as a way of learning Meteor. I wanted to offer it up to the community to scrutinise and critique and in the process hopefully learn more.

It’s currently deployed on meteor.com and can be found here: http://byron-burger-rater.meteor.com/
The project repo is here on my GitHub: https://github.com/adjohnston/byron-burger-rater

I look forward to reading your issues, opinions, advice or anything you can offer.


#2

that’s cool, nice work. upvote / downvote doesn’t seem to be doing anything for me. I like the design.

I like your code organization, it’s pretty easy to find things and see what’s going on.

One thing I would suggest is put your Schema definition and rules somewhere obvious. At minimum in documentation or code comments, just list out all the fields and field types. I like Simple Schema package because it enforces the schema rules and also provides some natural documentation for what’s happening.

one minor thing – the name ‘index’ for a template is a bit generic. I think it’s a list of all the restaurants ? Perhaps ‘RestaurantList’ is more descriptive.

good job!


#3

Thank you for the feedback. So no issues with how I handle populating the database? I thought that might be an issue but it was more of a feeling.

I know what you mean about the naming of index. I will rename that.

Others have voted so is it possible that the voting worked but you hadn’t realised because the list re-orders when a vote is cast? I say this because I thought the same thing a few times and that was the case. I plan on adding some sort of notice to make the user aware they’ve cast a vote.

On a side issue I don’t suppose you know of a way to handle only voting the once but being able to cast the opposite vote, meaning you could upvote, downvote, upvote but not upvote upvote or downvote downvote. I was thinking or splitting the ips array into an object with up and down arrays inside as a possible solution.


#4

I think the way you handle populating the database is fine for purposes of a learning app. Some things to consider for your data populating routine :

  • poll for data changes vs. check on app startup ( in the event that the app were to sit for months with no updates )
  • Handle restaurant closures as well as new restaurants
  • add a Byron.foursquareId field instead of using foursquare id as Byron._id ( in the event you switch data providers or use multiple data providers this will help keep things straight )

About upvoting / downvoting logic … I don’t know offhand. I would have to get in there and try things out.