I’ll admit that I have a lot of experience with things not going well in Ember.
Over time I’ve started to get a general workflow in place that I’d like to share.
When I have to debug it’s commonly performed from two points of view. Either the page didn’t render at all due to a javascript error,
or the page rendered, just not in the way that I was expecting. From there I find myself following the flow in the chart below.
A small companion guide
Start at the template. The template is the source of truth for what goes on the screen, and Ember’s handy inspector makes it
quick to confirm the state of all those bound values. If the page rendered incorrectly it means a bound value somewhere isn’t what I was expecting.
From there I go to each incorrect value and try to determine how it was set, essentially recursing back through the flowchart.
Blank screens and no error? Start logging. In some apps the way I’ve (poorly) set up my routes and their error handling will lead to a route swallowing
an error during a transition. If I come across a blank page with no error I’ll normally set LOG_TRANSITIONS_INTERNAL: true like the debugging guide
demonstrates. Then tracking down the failed route hook is a snap.
Check computed property dependent keys I’ve shot myself in the foot countless times from typos or plain mistakes in computed property keys. If I write a property whose keys don’t
correspond to the get() calls inside, I try to write a comment saying why.
I <3 developer tools I couldn’t get through my working day if I didn’t have the Chrome developer tools. Half of the items on my flowchart involve setting a breakpoint somewhere
in my app’s source code or in the ember source code. I often find myself setting a breakpoint at an obvious place, then navigating up the stack and setting more breakpoints closer to
what I think is the source of the problem.
Use error.stack When the browser pauses on an Ember error, there are many cases where the browser stack trace at that moment won’t be very useful. In that case, I check the thrown
error’s stack property. It often has a more informative list of places for me to check.
Debug two-way bindings with observers Sometimes I get plain stuck trying to figure out how a value is being changed in a component. Observers to the rescue! Here’s a quick example:
Ember.Component.extend({
heisenValue: "foo",
// If heisenValue changes for any reason, the observer will fire synchronously
// and show me where the change is coming from.
forDebug: Ember.observer('heisenValue', function() {
debugger;
})
});
Check the server response If my Ember Data models aren’t showing the right information I’ll always take a quick look at the network response
to make sure the data is what I’d expect before diving in further on the client side. It’s saved me a ton of time, especially when working on a new feature.
Take heart!
Debugging can be frustrating, but I’ve found having a consistent set of steps has made finding run of the mill problems much less taxing.
