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 
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 …
