Did you know: there is an ongoing project called ember-extension which adds an Ember panel to your Chrome Inspector.
It’s somewhat limited in functionality at the moment, but a lot of smart folk are working on it, and it’d be nice to crowdsource some ideas for what would be extremely useful to the Ember workflow. I’m not expert on it yet, but we have basic support for hovering elements and displaying what template they belong to, what controller is attached, etc., and a newly added overview of all the routes in your application.
What else should be added?
I’ll start:
Perhaps it’d be nice to, either in View Tree / Routes / both, right click on a route/view/template and select an option to copy a stub for Controller/View/etc.
e.g. if I’ve been able to make do with the autogenerated controllers/views for FooRoute, but now I need to change something about them, I should be able to right click FooRoute and select “Copy Controller Stub to Clipboard”, and then paste the following into whatever text editor:
Having used Batarang which is Angular’s chrome extension, I would really like something similar to it’s Scopes section, but for templates.
With Batarang you can highlight a scope then you get to see the list of properties that are defined on it.
With ember-extension, what I’d love is to have is a way to select a template and see the bindings that are present in that context. For eg:- In a posts controller backed by a Post model. Clicking on a template in the inspector would show a list of attributes on the Post model and anything else in the template’s scope.
Very helpful to quickly spot issues, that would otherwise require log statements.
Another thing I think might be useful is a Router/State diagnostic tool.
Consider that you have bunch of routes and you are clicking around to test drive the app. The extension could log the routes it is hitting with snapshot of the model, or atleast the serialized part. So if you eventually hit a snag you have some idea of how you got into that state.
Currently this is quite cumbersome and requires a lot of logging.
I was thinking earlier today that it would be awesome if you could use the Ember Inspector to figure out where the bottlenecks are. When hovering over a template / view in the inspector it would be awesome to see stats like how long it took to render, how many bindings / observers it has etc.
Not sure if the inspector can inject this kind of behavior into an app or not, but it sure would be neat.
@raytiley I use Ember.STRUCTURED_PROFILE to true to see the render times of views. It’s part of the instrumentation module. This would be super handy too in the extension!
Thanks for this @dsawardekar - I haven’t seen this mentioned anywhere! We should have a documentation page for this sort of thing - ‘Development best practices’ or something.
@machty One more thing I’ll add is the extension could explicitly show if there are bindings in your template that don’t have data for it.
For example:- If {{user.name}}, is bound but there is no user model in that context, there is currently no feedback shown. The property is just empty in the rendered template. You have to resort to logging to figure out the issue.
I love the idea of code generation. However I have a couple of concerns with the specific controller stub example you gave:
It assumes you are attaching controllers to the namespace. However we could be using modules (like app-kit or the extension itself). One example with ES6 modules would look like this:
var FooController = Ember.Controller.extend({});
export = FooController;
There is also the case of coffeescript, but I’m not sure if this is something we should account for.
If the route hasn’t been visited yet, I can’t think of a way for the extension to know whether you need a Controller, ObjectController, or ArrayController.
A user might end up changing all of the generated code except the name of the controller, which can already be copied from the extension. Maybe if the generated code was bigger, these changes would be negligible?
Maybe this has been mentioned, but it would handy if there was a “go to” link in each row of the routes inspector. Basic quick shortcut hyperlink that takes you directly to that route in the browser. This would mostly work for index routes. But routes with dynamic segments perhaps you could prepopulate a pulldown with associated IDs. Maybe limit this functionality to only when using fixtures where all the ids can be known at run time.
The main idea is to provide a quick and dirty way to “browse” through the structure of you app. Helpful when the UI navigation links and interface is still a work in progress.
