Debugging Ember
Ember has a powerful developer toolset. Often a console.log or debugger statement are enough to get by, but Ember's tools allow for a rich and interactive way of finding out what is wrong and how to fix it.
Handlebars Has
The tag in a handlebars template operates the same way as a debugger statement does in JavaScript. When the renderer hits the statement, it will stop execution and await input.
In the debugger session a few key functions are available. The one I use most often is get. Just like in backing code, get(<path>) will return the value of the Ember object.
Two other functions, view and context, are also available. context is helpful to make sure that your template was called from the right place. If the context returned is unexpected, the template may have been called from the wrong component. view returns the current view.
If the full power of a debugging session is not necessary, it is also possible to display values directly in the template with a statement. takes two arguments: a string description and a variable to log. can be useful to see what a variable looks like at render time.
Ember Has an Inspector
When logging isn't enough, the Ember Inspector allows for direct developer interaction with Ember.
The Ember inspector lives along side Chrome and Firefox's web inspector. It can be accessed in the same way: right click on the page and go to Inspect.
I tend to look at the Data tab first. The tab is pre-loaded with all of the types that are defined on that page. Objects that have been fetched show their number and each object can be clicked on and inspected.
It's rare for me to see an object with incorrect data, but that's also a good thing to eliminate first. I usually find that an object I expect to have loaded hasn't. The inspector also allows for editing objects inline. This can be useful for getting to edge cases quickly.
Using the Data tab sometimes causes the error to disappear. These Heisenbugs are caused by the fact that invoking the Data tab causes Ember to recompute the objects values. A Heisenbug is a clue in itself, however. If the data is available after the page is rendered, it is possible that a race condition existed somewhere in the cycle. Or lifecycle hooks may have been called incorrectly (did you call super?).
Sometimes more robust manipulation is needed. At any time the $E button on the data tab can be used to copy an object to the console. There it can be examined and manipulated by any function on the page.
The Promises tab is the next most useful tab for me. Ember is very good about handling asynchronous events. That makes finding mistakes in event handlers difficult to spot. Looking at the Promises tab it's easy to see which promises have been fulfilled and which haven't. That greatly narrows the scope of the investigation.
EmberJS has a good write up of everything the Ember inspector can do.
Running the Inspector in IE
... or Opera, or your iPhone, etc.
Once you've gotten used to the inspector, it can be rough to live without it. The Ember remote inspector can help with that.
It's intended to give all of the power of the Ember inspector for mobile devices, but there's nothing that says the remote browser has to come from a mobile device. It's a great way to get the power of the Ember inspector in browsers that aren't Chrome or Firefox.
Once installed, you can visit localhost:4200 from any browser on your computer and get the full power of the inspector.
To use a device like an Android tablet or iPad, a couple of extra steps are needed. I find it easiest to run a web proxy on the development computer. Fiddler works well in Windows, and Charles works well on a Mac or in Linux, but any web proxy will do.
Both of the suggested proxy programs will need to be configured to allow external computers to connect. Once that's done, you can go to your device's network settings and configure the HTTP and HTTPS proxies to point to your development computer.
After that you can visit localhost:4200 on your device and debug your application.
But Wait, There's More
These are the tips I use most often when debugging my Ember code. It is by no means an exhaustive list. If you have any questions or a tip you'd like to share, please send it our way at hello@mutuallyhuman.com.