Aurelia: [RFC] Chrome inspector (placeholder)

[fkleuver]

💬 RFC

🔦 Context

💻 Examples

[brandonseydel]

General Thoughts

Detection

• Determined by scanning elements for $controller/$au (do we show without au being started) stopping tree search after one find (may add something to global to have earlier detection)

• If true icon is lit up and maybe check for debugconfiguration to determine if in debug mode vs prod (also print to console some information information and possibly a link and additional information)

• If debug popup window on icon click will allow open inspector panel for aurelia directly
  else display message

Design

2 panels should show up in debug tools one for performance and one for layout

• Performance
  
  
  
  • This will display perf timings in the hooks to determine render times of said components
  
  
  • Also scan for dirty checking and other things that may have negative performance
  
  
• Layout
  
  
  
  • Provide a layout view of the application that has 2 way inspect from the real layout to the debug panel
  
  
  • Underline/highlight all the different resource types and have a search that works for custom element names non kebab as well as kebab
  
  
  • show arrows above bound properties one right if from-view one left it to-view and both if bi-directional (on hover possible config)
  
  
  • Interpolation will display the original expression in line with the value above (if member access then also allow the member to be examined) (on hover possible config)
  
  
  • Bindings will display the original expression as well (if member access then also allow the member to be examined) (on hover possible config)
  
  
  • When a element/attribute/value-converter/etc. is selected display information in an editable side panel which can manipulate the bindingContext that is associated to that resource.
  
  
  • Have the ability to "go to definition" from a selected resource
  
  
  • Have the ability to "force bind" for debugging purposes
  
  
• Plugins
  
  
  
  • Have the ability for plugin authors to hook into the aurelia extension to provide more information that may not be possible reading only the view models. (foreach plugin that has a devToolFunction add a tab etc.)
  
  
  • The router will implement this and have all the abilities as well as state so one can see redirects etc.
  
  
• Events
  
  
  
  • Allow event proxy creation on delegate/trigger to capture user interactions that can then be later replayed. This would be useful for test suites or just quick one off testing after changes. Snapshot of the VM before/after and stored in state to "rewind"/"ff" would be neat.
  
  

[Vheissu]

Adding onto this, the ability to enable a production mode to prevent the extension from being used on some sites would be great. Other frameworks/library extensions offer this functionality.

[CuddleBunny]

Came here from a post in discourse (https://discourse.aurelia.io/t/aurelia-chrome-extension-and-vnext/3004). I like the idea of using web-ext to give Firefox some love.

[alexdresko]

Does anyone know what is required to make the inspector more dynamic like some of the other framework inspectors are? It'd be nice to see real-time updates on the model, as well as make changes to the model in the inspector.

[fkleuver]

Yeah we got a scheduler that can deal with that.

[davidlav]

+1 for Firefox

[EisenbergEffect]

One thing I had pondered was just building an Aurelia app that you could drop in like a plugin to your own app, that will enable an inspector overlay. This wouldn't use the dev tools of any particular browser at all. Just tossing this out there as an option. No need to deal with browser-specific APIs or passing/consuming data across process boundaries.

[CuddleBunny]

@EisenbergEffect - I'm down with this approach. I've used other integrated stuff like weinre and vorlon.js for remote debugging with some success. I think more importantly than how it is built we need to think about how it provides value that the existing browser tools don't. @brandonseydel's post is a good start.

[davidlav]

Down the road, once the extension is operational, it would be a great idea to weave its use into the official docs/tutorials. The first time I ever used it to inspect a binding context years ago when I was first learning Aurelia, that instantly made so many things "click" that I just hadn't quite gotten over the course of reading the docs (and being brand new to the whole concept of SPAs/data binding in general).

[alexdresko]

It seems like implementing your own inspector would be difficult. Like, on the surface it might be easy, but once you get into you find that Google probably has a million lines of code involved. Not trying to scare anyone, and I don't know for certain... Just thinking out loud.

[fkleuver]

It shouldn't be more than a few thousand lines. The bulk of the work will be the UI aspect - how to represent the app's scope structure, binding contexts, controllers, etc, and how the user can interact with the visual artifacts.
For getting the necessary data to feed to the UI (and keeping it up-to-date live) we already have some easy-to-use API surface in the framework itself. Integrating that with a chrome extension involves a bit of boilerplate but nothing complicated. We've done that before :)