My Notes

Joining a new company to start working on a medium-to-largish Ember.js app has been an enjoyable and challenging experience. Below are my notes about ramping up and contributing to an Ember project.

One piece at a time

Ember.js is different. It is different than Rails, different than Rails + JQuery, more than Backbone, different than Angular, Knockout, and React.

Ember is focused, but comprehensive.

Influenced by the learnings of the Rails community, Ember values convention over configuration.

The basic pieces of scalable web applications have been distilled into Objects that Ember is models around.

Router Route Controller - ObjectController | ArrayController Model Helper View.js | Component Template.hbs

Third party libraries, npm, and bower

All pieces layed out

The router declares the Routes available. Routes are either provided by you, or automatically through the Framework. Routes can do the following: ____ and are typically used for the following: * setupController with model calls @get('store').find("object")_____.

Routes pass their results to Controllers.

Controllers perform these common functions: ________________. Properties, functions, and ???.

eg: ImageController

width: "500px",
height: "500px",
format: ".png",
alt: "An alternate description about this Image"

Controllers hold application state and properties/fields that are derived from Model fields.

Views javascript (.js) can declare tags, class, ids, and also behaviors for a piece of HTML Content. View handlebars (.hbs) uses Handlebar syntax and can reference controller variables.

Generally speaking, Views should not reach out to Models for information. Rather, they should be provided by the 'model' object on the Controller.

---

Here are 3 tips for getting started with Ember.js. (Fall 2014)

An informed approach

Like any tool, knowing how to use it makes all the difference.

Learning Ember.js is a precarious adventure. It requires a lot of effort to acquire the concepts and mentally arrange them in a way that integrate: strategic product and business ideas, ux, and system requirements and design with the tactical knowledge of syntax and programming architecture and structure and testing to write and perform the logic. Decomposing an application into specific, meaningful pieces enables a more continuous flow when reasoning about the performance and growth of a system.

Writing code is the distillation of the generic system requirements into syntactical, executable representations as software. An application is merely an instance of a certain Class of Application.

Here's a rough sketch of Ember, for me:

And here's a Gist of the flow a default Ember Flow.

Here are some items I found useful. Reading these, then writing software, then re-reading these has been helpful. Ember.js doesn't all stick on the first pass. It takes exposure, like most technologies and ways of thinking.

• Getting Started Guide - http://emberjs.com/guides/getting-started/
• Vic Ramon's Tutorial - http://ember.vicramon.com/ember-object-flow
• Vic Ramon's Github Repo - https://github.com/vicramon/ember-hello-world
• Toptal's [A Guide to Building Your First Ember.js App](http://www.toptal.com/javascript/a-step-by-step-guide-to-building-your-first-ember-js-app
• Developing an Ember Edge
• Envato's Ember Components: A Deep Dive