There’s been some chat on MM about debugging Ember, so I thought I’d kick off the convo here. This is not an exhaustive list, but just a few things I can think of right now.
Ember Inspector
I use Ember Inspector Browser Extension (EI) a fair bit, primarily for:
-
Component Inspection. EI can tell you what components you’re looking at and what instance data they have. This is a convenient way to quickly tell what data the client has without having to stick
console.logsin the code.
-
Route Inspection. Discourse’s client-side route system is relatively complex. Especially when I’m adding a new route, I use the “Routes” tab in EI to tell me what route is actually being loaded, and whether I’ve got the naming right.
Direct Modification of Discourse
When you write alot of plugins and themes you get very used to having the take the core Discourse code as a given. You try to follow Discourse patterns and conventions as much as possible. However, this can sometimes mislead you into avoiding one of the simplest methods of figuring out how to achieve your goal, just change the core code.
Sometimes you just need to get in there and completely overwrite, remove or replace Discourse classes and methods when you’re trying to figure out how to achieve an outcome. This may sound obvious, but I’ve found that you get into a pattern of “integration thinking”, always thinking about how what you’re doing will inegrate with Discourse in production, that you waste time fumbling around trying to build the perfectly integrated version from the start.
Now, that “integration thinking” is good. You need to think that way to write good plugins and themes, but you sometimes need to remind yourself to break out of it.