My first @meteorjs app - @hackfind v0.01
It's been a busy weekend of hacking. I have my first iteration of @hackfind up & running at www.hackfind.com ! It's pretty limited and crappy looking... but I'm starting to get my head around how the pieces of @meteorjs come together.
Hackfind is meant to (eventually) help you find people to work with on their coding projects or your own. The idea is you broadcast whenever you sit down to hack and the projects you're working on. Then people can request to join you, say at a cafe, co-working space or even remote pair programming depending on where you're cranking.
I spent saturday rewriting the meteor parties example in CoffeeScript which you can grab from a branch of my project here.
I made a big blue by forgetting to run meteor add coffeescript for an hour and not knowing what why things weren't working.
I thought I'd detail the rest of this post on what I got stuck on and do a future polished post on how I understand the pieces of meteor come together. When you grab the examples (parties & todos) everything is dumped into one long client.js file. You really have to break it down to understand how everything fits together. It feels quite different to backbonejs from my perspective.
The first thing to get is the <template> tags. As from the docs:
HTML files in a Meteor application are treated differently from other frameworks. Meteor scans HTML files in your directory for three top-level elements: <head>, <body>, and <template>. The head and body sections are separately concatenated into a single head and body, which are transmitted to the client on initial page load.
Template sections, on the other hand, are converted into JavaScript functions, available under the Template namespace.
In essence for every <template> tag you define, you have a set of javascript functions that act on that template.
<![CDATA[// <![CDATA[ // <![CDATA[ // <![CDATA[ // <![CDATA[ // ]]]]]]]]]]><![CDATA[><![CDATA[><![CDATA[><![CDATA[> // ]]]]]]]]><![CDATA[><![CDATA[><![CDATA[> // ]]]]]]><![CDATA[><![CDATA[> // ]]]]><![CDATA[>]]>
I found it useful to break my templates into separate files and put the script that was related to each template into it's own file.
It took me about half an hour to figure out that when a handlebars template refers to a piece of data like {{ creatorName }} it is actually looking for a function creatorName scoped on the templates JS object.Â
Template.hacks_detail.creatorName = -> displayName(Meteor.users.findOne @owner)
The exception is the {{#with hack}} {{/with }} template operator which knows to look for data on 'hack' which from the gist above turns out to be a function in itself!
Using the "Session" variables to control what was visible on the page felt quite awkward. For example showing a create modal dialog. I have more thinking and feeling to feel right with this.
It also took me a while to follow the flow of context when using @_id or this._id in your template helper functions. The todos example uses this._id quite extensively. Basically when a template function is called within an {{#each listofobjects }} {{/each }} block, it magically picks up the id of the current object, but outside this scope @_id will be null.
The validation story is still unfinished... Looking forward to seeing how the meteor team approaches this. Also the usage of backbonejs seems limited and trivial as meteor already has it's own ideas of collections, views & templating taken care of. The Router is good for tacking push-state and url fragments, but I'm sure the meteor folk will provide their own router in the not too distant future.
Overall, I learned enough toÂ
Sign in (with github or your email address)
Let you create a hack (hacking session)
View all the hacks in the mongo database
Off to a good start and looking forward to doing more next weekend.
