I have this idea floating around in my brain about an Ember app sanity checker, perhaps called Ember Doctor, that will look at all your app code and warn you off possible errors/gotchas that might otherwise be tricky/subtle to solve. Perhaps this would be an npm command line tool, or perhaps it’d be a tab in the Chrome Ember Extension, but here are some possible things it could help out with:
Catch Lazy Computed Property Misuse
The lazy computed properties optimization introduced a little before Ember 1.0.0 requires that you “consume” (call .get() on) the dependent keys you specify in a computed property in order for that property to be properly watched for changes. It can be very tricky to debug when you don’t exactly adhere to this rule, and there’s very little you can do other than saying Kris Selden’s name three times in a row until he materializes and points out the likely culprit. It’d be possible (perhaps only for an npm command line utility) to parse your app’s JS code into an AST and check that you specified x as a dependent key but that you don’t actually call this.get('x'), which can lead to subtle errors.
Let you know of nicer/newer Ember patterns
e.g. Ember Doctor could detect that you do something like
var SignupModalView = Ember.View.extend({
elementId: 'signup-modal',
didInsertElement: function() {
$('#signup-modal').something();
}
});
and then provide the following suggestions
1. Possible refactor: replace `SignupModalView#didInsertElement` with a
more descriptive method name, and call `.on('didInsertElement')` on the
method so that it will run at the same time that `didInsertElement` would,
e.g.
moreDescriptiveName: function() {
// `SignupModalView#didInsertElement` code here...
}.on('didInsertElement')
2. Refactor: Use `this.$()` rather than `$('#signup-modal')` to get the
jQuery object associated this this view's element
3. Minor quibble: use `Ember.$` instead of `$` in case your app ever needs to
function in an environment where `$` is not available as a shorthand for
`jQuery`
This can also be used for things like suggestion Ember.computed.alias instead of somePropertyNameBinding, or any of the recent patterns that are meant to replace old ones that haven’t been officially deprecated yet.
Suggest when to use Ember.run
At the very least, this could catch setTimeout usage and suggest Ember.run.later instead. Maaaaaybe it could be smart enough to detect when you’re providing a third party library a hook into an Ember Object without wrapping the contents in an Ember.run, though I have many doubts.
Parse Router.map, detect invalid link-to’s
Ideally you should have 100% coverage in your test cases, but in case not, this would allow you to catch a failing link-to without actually having to navigate to the route/template containing the link-to to see the error.
Anyway…
Ideally all of this would be doable within Ember Extension; just being able to go to your Ember Extension tab and see a laundry list of possible improvements would be really nice, but there are limitations once code has been minified, or if the check that Ember Doctor needs to make digs into the realm of what can only be done with a JavaScript AST vs just some dumb regex. But either way, whether it’s an Ember Extension tab, an npm package, or both, I’d like to collect some ideas from everyone as to what’s been painful to debug, enlightening to finally discover (such as newer/more refined Ember patterns), and see what the best tool would be. Or maybe this is a crappy idea; I wanna hear that too if that’s the case.
