Ember Inspector - Call for feature requests, pain points, and contributors!

Ember Inspector - Help shape the future!

We’re pushing hard to make Ember Inspector the world class dev tools you deserve, and would love to get your input and help! We would like to hear about feature requests and ideas you have, pain points you have experienced, and anything and everything you can think of, that you would like to see make it into future iterations of Ember Inspector.

Things we already plan to work toward and could use some help on include:

  • Engines support
  • Notifications of what changed between versions
  • Accessibility and colors
  • Fleshing out more in depth developer and user docs

One thing I’d love to see is visualizing data flow. Like data down/actions up how it flows through the system.


Thanks for all the great work on this valuable tool. Here are a few ideas on what would make it even more awesome:

  • an easy way to go from an element in the DOM inspector to a component view in the Ember inspector
  • Clickable columns (to sort) in Data view
  • an view to help trace actions though my component tree (not sure yet what this would look like)

I big thing for me would be a object data view similar to the CSS Computed section. Being able to quickly see the entirety of the data on a component or object would be great, rather than having to uncollapse all the mixins, etc.

I’d third the request to gain some visibility into what actions are being fired. Vue’s dev tool has a nice feature like this. I know it wouldn’t be quite the same. What I’m thinking being able to see a list of all actions fired, with the ability to filter and see all actions that made it to a route and which route, etc.

Thanks for all the work you’ve done on this tool! It’s really improved over the last couple months.


I’d like to have few features in ember inspector:

  1. Easy navigation from Dom element to corresponding component or controller.
  2. Ember error debugging or explanation with possible solutions how to fix.
1 Like

My highest priority request is getting comprehensive integration test coverage such that PRs to Ember that break the inspector or cause it to emit deprecations cause test failures.

It shouldn’t be solely up to the inspector maintainers to try to chase Ember. People making changes to Ember that break the inspector should at a minimum be aware that they’re breaking it, and ideally should actually fix it before merging their changes to Ember.


Second highest priority request: discover Ember apps in iframes and let people pick which one to inspect.


We do have tests around that in the Inspector. I think we just need to make sure people are checking those before publishing new Ember versions.

Persisting text filters & other options(checkboxes) selected on the view that was last accessed across reloads would be sweet!

If we can start differentiating attributes passed into components from those internal to it in the context view that’d be helpful :slight_smile:


Understood, but I’m talking about making those tests run when Ember changes, in the context of an Ember PR.

The reliable way to “make sure people are checking” things is to enforce them via CI.


We’re using ES6 class and decorators a lot (with or without typescript), but inspector doesn’t collect properties that been defined by decorators, this is the most annoy issue currently. I’d willing to help if possible.


Another one, I wish inspector can keep what we searched for last time, especially in component tree view.


Thank you for all your work! I think the one feature I have always wished existed is being able to sort through the Ember Data models by attribute.


Click to sort column headers and resizable columns are the first things that come to mind. Too often I can’t fully read the data in the column I’m looking at or there doesn’t seem to be any rhyme or reason to the ordering.

A better connection between components/controllers and their DOM elements would be nice, but I can’t quite picture how that’d look in my head.

And last, I’ll chime in with being able to better track actions and what is being fired from/to where.

Thank you for all the work you all put in towards this essential tool!


This might be off topic, but what are the main selling points / use cases of Ember Inspector? My general debugging flow is to

  • set debugger in route hooks and component lifecycle hooks
  • use getOwner(this).lookup, or MyApp.__container__.lookup or temporarily inject objects (like services) to whatever context I set my debugger in to inspect the state.

I’ve never gotten used to using Ember Inspector, so I’m wondering what I’m missing or if there are additional benefits I’d get from looking at it more often.


React Devtools has a feature that is very helpful when optimizing component performance. It’s called Highlight Updates and it shows what part of the component tree was re-rendered as a result of an update.


I think the general use case is probably for people that don’t know how to delve into the internals of Ember. It makes debugging in Ember more approachable for devs of all ranges of experience.

It also provides a nice visual interface for looking at things like data, components, etc. Getting it out of the console and into a nicer interface can sometimes make things simpler to debug as well. Some devs are just more visual than others as well (i.e. prefer to use SourceTree or other Git gui over terminal/command line). It helps support those folks.

1 Like

For my team and the Ember apps we’re building, Engine support is important. I would love to help out with this!


We would love for you to help with this! :grinning:

There’s one item I remember us discussing at EmberConf a few months ago that might be worth discussing again. I think it is worth asking the question “what IS the Ember Inspector?”

Is the Ember Inspector:

  • an integrated devtool addon that seeks to improve the Ember debugging experience
  • a curated set of devtools for various key pieces of the Ember ecosystem that enhance the Ember experience (currently focused on debugging)

Although those two statements read very similarly, I would argue that the second is actually QUITE distinct in the long run from the first.

At the moment, the Inspector acts more as an addon - “we’ll solve one key issue for you and solve it well”. But if we take a step back for a minute, I would argue that the Inspector actually is solving three things right now

  • providing the framework and browser extension necessary to work in-tandem with an active running Ember app
  • providing tools for debugging the Ember framework itself (primarily the view layer, but the ability to inspect other aspects as well)
  • tools for debugging the Ember Data addon

Of those three, the last one (Ember Data) is what intrigues me. Should the Inspector aim to take a core/addon approach more like Ember CLI instead of continuing the “all-in-one solution” that we’ve traditionally had with the Inspector? For if right now we roll some key functionality for debugging certain addons into the Inspector but in the future could allow the Inspector to be more pluggable, what types of experiences could we as a community build more easily together?

Just as Ember itself increasingly has shifted toward a stable core / experimentation through addons approach, so also the Inspector might benefit from a similar philosophical shift. If we did that, it could benefit everyone in the long run, as it could move maintenance of debugging functionality away from inspector maintenainers. Instead of Ember Inspector maintainers having to carefully weigh ongoing maintenance costs within the Inspector for each new feature, we could move experiments to addons and co-locate debugging functionality within the same addon that provides the functionality.

Ember Data is a prime poster child for this. As Ember Data contemplates simplifying its APIs, it may get complicated to keep the Ember Data Inspector pane in-sync and working smoothly. But if the Ember Data addon instead exposed an Inspector plugin that worked with the current version of Ember Data that was loaded in your app, the Inspector plugin could be tested via CI alongside of changes within Ember Data and the Ember Inspector could just happily keep working.

This then also opens the way to other addons exposing their own Inspector plugins in the future. I could see use cases for other addons that handle data and state of various kinds (Ember-CLI-Mirage and possibly Ember-Redux?) but there might be other addons/use cases further afield that could benefit from it as well (form validation, possibly mapping).

And if we’re really dreaming - could we build in tooling that helps control deploys or Ember CLI itself? IE if Inspector stops narrowing its focus to debugging only, is it actually the central UI we’ve all sort of wanted for viewing and controlling Ember apps as a whole? The idea excites me :slightly_smiling_face: There might be something there if we explore this …

What I would envision is coming up with some public api that the Ember Inspector provides that allows addons to register themselves. By and large, the Inspector UI acts as a series of routes, so if we allowed addons to register new engines and then had the Inspector map over those extracting out engine names we might be mostly there already …