Meteor Template Naming Technique

If you haven’t gotten to try out Meteor I would not waste another second and begin the tutorials immediately.

I am writing this from a position of having been doing Ruby on Rails professionally for several years and only having played with Meteor for a few small projects (Paypal Battlehack entry and Meteor Paypal). I have, however, run into some confusion when naming my Meteor templates. I initially followed the technique demonstrated in most of the documentation of using camelCase and something like my users index template would be named something like:

<template name=’usersIndex’>

and then referenced via:

template.usersIndex

This methodology, while great for initial pages can get a little hairy when you start using more and more of the “partial” mentality so prevailent in Rails. I really prefer this idea because I do believe in the DRY philosophy and I think any time I have to Copy/Paste code there is potential for a partial. It was through adding these partials that I would come up with names like:

<template name=’userProfileEditForm’>

and

<template name=’eventParticipantShowInformation’>

which I thought were incredibly hairy and did not give any sort of insight into where they could be found. I then realized that the malleability of Javascript could really come in handy here. I began renaming my templates to reflect their location such as:

<template name=’users/profile/form’>

and

<template name=’event/participant/information’>

where I would create directories mapping each of these names separated by the slashes. Unfortunately this does not allow us to continue to use the methodology so bedrock to the Meteor demonstrations because doing:

template.event/participant/information

is not valid javascript. Here is where that malleability of Javascript comes into play. By changing the dot-notation to a hashmap notation we are easily able to access the template with:

template[‘event/participant/information’]

this works in every instance and easily allows us to structure our meteor application keeping directories and file names small and consice. I also perfer this method as opposed to using snake_case because the slashes give a more directory-like feel and allow for people coming from rails to append the famous _ for partials such as: “_form”

I know Meteor is still in it’s early stages and this type of dynamic naming could potentially become unavailable but it’s a solution to a headache that I had really enjoyed using. I am also extremely grateful for all the work the Meteor team has done to make such an incredible framework. I strongly recommend anyone who hasn’t read it read the book: Discover Meteor as it is incredibly useful.

 

Thanks for reading!

//davidbrear (@davidbrear04)