Debugging in One Place

There are many ember debugging methods, but they are scattered and the can be a long and difficult to remember. I was thinking it would be good to collect things in one place, w simpler accessors when possible, so wrote the initializer below. I find it useful. Curious what others thought and whether we should try to do something more complete.

var initializer = {
  name: 'debug',

  initialize:function (container, app) {
    app.debug = {
      controller: function(name){
        return container.lookup("controller:" + name);
      route: function(name){
        return container.lookup("route:" + name);
      view: function(domElem){
        return Em.View.views[domElem];
      registry: container.registry.dict,
      routes: Em.keys(app.Router.router.recognizer.names),
      store: container.lookup("store:main"),
      typeMaps: container.lookup("store:main").typeMaps,
      templates: Em.keys(Ember.TEMPLATES),
      inspect: Em.inspect,
      observersFor: function(observedObj, key){
        Em.observersFor(observedObj, key);


  1. How do you use it to debug?
  2. What does it tell you?
  3. What use cases does it help you discover?

Looks like a bunch of centralized shortcuts for fetching common ember object. App.debug.controller(‘albums’) anywhere during debug instead of App._container_.lookup(‘controller:albums’) yadda yadda. Looks cool.

@tarasm meant to be used in the console. not sure it helps u discover any use cases, just simplifies and involves less keystrokes as kingpin2k has illustrated. think of it as shortcuts.

Very nice. This is a pattern I have found useful. Define a global “log” function.

App.debug = true;

App.log = function (context, method, arguments) {
    // centralize reference to console.log
    // Example usage
    // App.log("SomeComponent", "handleMethod", input);

    if (App.debug) {
        console.log("App Debug %s %s %O", context, method, arguments);

The primary advantage is that is centralizes my use of console.log. And I can easily turn it on or off. And should it become necessary I can put a bunch of extra logic inside the function if I want to be selective about what specific debug statements I want to so or hide.

I tried to be generic about the arguments that are passed to this function. But one could customize to whatever use case you want.

I could see a use for combining your concept with centralized logging method.


This is cool. I had much the same set of function, but not wrapped in an initializer. I’ve created a Git repo and bower module that contains this. Happy to take any other additions that we think would be good to have in here:

1 Like