Debugging an Ember Octane App

So you have been asked to fix a bug or to explore functionality in an Ember app. Have a humungous code-base and have no idea where to start! Well, you are in luck as I'll be showing you some tips on common debugging and reverser engineering ways in Ember world.

Step 0

For debugging with ease, make sure sourcemaps are generated for your builds. If they are not being generated, then go to ember-cli-build.js and pass:

  sourcemaps: {
   enabled: true
  },

as options to EmberApp() function.

With this enabled, a special kind of file (aka sourcemaps) will be generated along with the bundled output, which the browser can use to understand the original source code you wrote from the bundled output.

While there are many ways to debug an ember app, we will be mostly looking at debugging with the help of ember inspector in this blog.

Finding the component which has the bug

Let's say you are debugging this page: www.emberobserver.com/code-search.

And you wanna figure out how the code search section is built or debug it.

To do that you have to find out what component is used to render the code search input box dom. But how do you find which component has the code for it?

The easiest way to find the respective component files is by using the Ember Inspector

Steps to install the extension for chrome or firefox can be found here.

Now with the extension installed, refresh the page and open dev-tools. You will see that a new tab named ember has come in the dev-tools status bar. Click on it!

Now click on the Components tab there

You will see a list of components used on the page.
Click on the mouse with a square in the background icon.

Now move your mouse to the code search dom element and click on it.

The Ember inspector should have highlighted on the component used for rendering that particular code search section dom.

From what we can see, it seems to be a component named CodeSearch. To confirm if there exists a component in that name, let's search the ember-observer code-base for files which contains the name code-search.

And voila there seem to files:
github.com/emberobserver/client/blob/master/app/components/code-search.js and github.com/emberobserver/client/blob/master/app/components/code-search.hbs present.

On the right side on the pane, you will get to see all the properties used in the component.

Hover over one of the properties and click on the $E text to inspect the prop value in the console.

Debugging the component

Now that you know how to find what component is being used in a place, let me show you how to add debuggers or logger statements in the component code.

The component mainly consists of two files:
the component.js file and
the template.hbs file

debugging the component.js

Debugging the component.js file is same as debugging any other javascript file.
You have debugger statement to stop the code execution at that particular line and console.log(variable name) to log variable values to the console.

debugging the template.hbs

In the template file as well you have the ability to add debuggers and log statement. But using them is slightly different.

You have helper methods to add debuggers and log statement here.

To add breakpoints in the template, you write the {{debugger}} statement.

Once the execution stops in a template breakpoint,
you can use the get(<path>) method in the console to get values of properties used in the template. For example, you can type get(this.name) or get(@value) to print those property values to the console.

To log property values used in templates to the console, use the {{log prop_name}} helper.

Finding the route and controller files for a page.

As you saw in the last section, finding the component files was easy peasy. But most of our data and logic mostly would likely reside in the route and controller files respectively.

One way to find the route and controller files is by looking at the URL of the page you are in. And then checking your router.js file to find which route and controllers may be matched for the URL.

But is there an easier way!.

Well, there is, thanks to ember inspector once again.

In ember inspector, you do get a routes tab which shows all the routes and respective controllers available.

What I usually like to do is enable Current Route only filter so that we only see the routes and controller used in the current page we are on.

This is particularly handy in debugging pages which have nested routes involved in rendering it.

Debugging ember data

While working with ember-data one thing I do keep open is the data tab in ember inspector. It shows the ember-data models available and the records stored in it.

The pane even has filters like New and Modified, where New shows ember-data records that have been newly created and not saved to the backend yet. And modified are saved records that have properties modified in the client and not synced up with the backend.

Extra tip

Measuring render performance

While building complex pages and components, I do recommend looking at the Render Performance tab in the ember inspector.

It shows the time taken by each component to render on screen.
If the render time is high, one thing you can do is optimise the logic and add loading state UI elements to the component.

I hope this blog post helped you in debugging your ember app with ease.

If you are still stuck…
hop on the Ember Community Discord and post you queries in the #help channel. Hopefully, somebody will be able to help you out.