Ember for Beginners, or, 'Where did my weekend go?'
01 Jun 2014Exposition and disclaimer
First, let me start off by saying that I appreciate the hard work so many people put into making open source software available. It's fantastic to be able to build a project based on foundations written by others to avoid constantly reinventing the wheel. I think that just about all the projects I mention in this post are great ideas and show a ton of promise. Don't let any sarcasm that may or may not crop up sour the mood.
OK, now that that's out of the way...
Ember (is a word for something that can burn you)
So I've decided to use Ember for my latest (OK, first real) web project. I'm not a huge fan of relying on naming conventions for functionality, but Ember's at least make sense most of the time, and so far the framework looks like a decent way to enforce (or at least encourage) some separation of concerns in the front end world.
I read a decent bit of the documentation (which seems a bit incomplete, but kudos to them for having as much as they do) and followed some of their Hello World example, changing some names as I went. That's where I ran into...
Ember gotcha #1: application vs. index
This one is at least partially covered in the intro tutorial and documentation, but I got lost somewhere between not naming my app "App" and moving templates into their own files instead of making my eyes bleed with a 2,000-line HTML file, and I got tripped up with this little detail.
Unless you're changing the names of the default ApplicationRoute, IndexRoute, etc., you'll want two templates to get yourself up and running:
application
The application template is your scaffolding. You can put it in your main HTML file inside a <script type="text/x-handlebars"></script> block (note the lack of a data-template-name attribute), or you can put it in an application.hbs (or whatever your extension of choice for Handlebars templates might be). A simple example of the application template might look like this:
Notice the {{outlet}} tag (or "helper"). That's where your dynamic content will be rendered—dynamic content that will first come from . . .
index
The index template (again, unless you've changed names/routes, but you're a beginner like me, so you're not doing things like that . . . right?) is the first template/view that will be rendered into your {{outlet}} when a visitor hits /, your root URL. An example (OK, a really bad example) of an index template might be:
You, um, probably want more than this here, but you sort of get the idea. You don't need an {{outlet}} helper here unless you're planning on having subroutes that you'll want to render inside this template.
Ember gotcha #2: Array controllers and templates
I don't have much of an introduction for this one, but I'm going to add it in here anyway. If you're looping over the contents of an array in a model (say, a fixture you've set up with multiple members for a mock-up), you might not be able to get the {{#each}} helper to work quite the way the docs say it'll work. In order to properly loop over a plain model I set up, I ended up using {{#each item in controller}}—using the literal word controller—instead of the {{#each photo in photos}} syntax (where photos is the model name) used in the docs.
OK, that's enough noobery for one post. Next up: Making all this play nicely(ish) with Vagrant.
I'm trying a sort of new thing with comments. Since this blog's hosted by Github anyway, to comment on this post, leave a comment on its Gist. Feedback is welcome, as are any corrections/advice.